actionitem

Table stakes - or should be. BUT...this is where the primitives vs. up the stack cloud approach can hurt. Primitives are great until you have to "manually automate" every single of them vs. have higher level policies that control a ton of items in one shot.

AI-driven IT automation is an essential component in managing complex hybrid and multiclouds. That's especially true for DevOps over a never-ending stream of cloud-native microservice builds and deploys.

Especially with hybrid and multicloud, automation is critical. Humans will not be able to keep up with the changes needed, policy and automation must be considered during the roll-out, not simply scripting after deployment. Like security, it needs to be baked into the process.

In cloud native workloads, automation matters the most, as you gradually move to migrations of legacy workloads, it matters less (as of today). I believe automation has to be looked through two high level lenses CREATIONS (build) and OPERATIONS (Ops).

Automation and orchestration are key components that simplify an individual cloud. These capabilities will be needed in hybrid cloud environments. One way this can be achieved is automation for a specific plane - e.g., backup, recovery, data placement in the data plane.

Beware: AUTOMATION in CREATION PART IS A TRAP. You want to make sure Operational Automation is Solid.

@stu Feels like we're also into imperative vs. declarative models. Has to be more "here's what it should look like at the end / desired state" than specify every precise item.

In terms of AI pipelines, what happens when edge and cloud are converged is that more data ingestion, modeling, training, serving, and inferencing moves edge-ward, having less need for roundtripping to cloud. The slippery slope to "autonomous standalone cloud."

Compute is moving to the Edge, and to the device in the Edge. Smart sensors and smart devices are running inference code in memory. This provides real-time state. These devices need to communicate with other devices in real-time to make real-time operational decisions..

First reaction is....feels like we're still a ways off from this truly happening beyond markecture. I would think about auto-scaling every layer of the stack to deal with highly variable torrents of incoming data.

(edited)

In short it won't but you can make
tools,
platforms,
provider,
and best yet architectural
choices such that you control interoperability and portability yourself. For each workload assign a portability and interoperability score. Make it a must for all workloads

@sarbjeetjohal Interesting idea, but to score workloads, you need a pretty well defined "our stack" architecture. Are enterprises defining their cloud defaults with that precision?

Hybrid often hurts on the auto-scaling side given on-prem not being as auto-scaling by nature. While cloud is, we're pulled into lowest common denominator when merging. Feels like AzureStack and Outposts come to the forefront over time in this area.

..The real-time state graph databases in memory, and ability to share state across all the local device nodes will require new architectures, probably based on Arm processors.

Never marry a cloud, just DATE ;)

@sarbjeetjohal sounds like you're saying all relationships are transactional :P

(edited)

@andriven From an IT perspective, I agree. From an OT perspective and vendors specializing for specific industries, this is moving fast, IMO!

utility pricing for one...#hybrid

DevOps techs are a key piece of the hybrid equation . that often get overlooked. It's key that continuous integration/continuous deployment repos and workflows span public and private clouds, leveraging Kubernetes for orchestration.

Though it's premature to say the Istio mesh is key to hybrid app DevOps, a hybrid-spanning network virtualization fabric is key, along the lines of what VMware and Cisco offer.

A good way of looking at this is through different planes connecting the nodes of a hybrid cloud. Network plane is fundamental, data plane allows sharing of data, control plane automation, security plane, etc.

In Hybrid we manage following:
- Compute (easy w/ O src tools)
- Networks (hardest part is this)
- Storage (easy w/ O src tools)
- PaaS components (Message queuing etc - hard b/c vendor specific APIs)
- Applications (need robust monitoring, O source can help here)

and add security to that mix which apans, compute, networks and data...... Operations become pretty messy pretty fast...

What is absolutely essential for hybrid cloud is a centralized policy console to set and enforce trust, encryption, RBAC, etc over public and private apps, workloads, data.

I'm going to cheat and expand the question a bit - before services/capabilities it's the right mindset and someone in the org who has the right technical/architectural skills with enough political capital to even start down the services/capabilities path.

(edited)

Chatting with a friend at a large private software SaaS shop, they actually quantified the $ value of accelerated development speed by going all in on AWS vs. the potential cost of lockin (rewriting code down the road). They went all in on AWS - became a competitive edge.

(edited)

The DOD argued that one cloud is simpler, cheaper, and safer than multiple clouds. For small businesses, this may well be true. Is there a perfect cloud? For large businesses with many SaaS clouds & many departments already using different clouds, it would be difficult!

@andriven Good example of where it is possible and beneficial!

I think the benefits of centralized cloud sourcing are considerable: efficiencies, comprehensive visibility and policy, etc. But there's the obvious danger of lock-in. In point of fact, enterprises should have a dominant public cloud provider within a multicloud archtct

@andriven I would love to see their calculations, though I assume that's proprietary.

@jameskobielus It definitely was - happy to discuss it more offline and put you in touch with some folks.

Enterprise users are evaluating cloud platforms based increasingly on their support for machine-learning workloads. A big part of that is the extent to which a cloud platform has high-performance GPUs for AI model training and inferencing.

The low hanging fruit in this analysis is the choice of SaaS applications. If you use Microsoft personal computing, Office 365 is the obvious cloud to use. If you have a large number of Microsoft applications using Windows, Microsoft Azure is an obvious choice.

because cloud usage is mainly starts with devs, ease of use (of Portals and APIs) is one big factor, As we move Operational Workloads to Cloud (non-cloud native), #CloupOps and Spend become two important aspects.

One of the ways that we have ended up with #multicloud is that there is not a comprehensive strategy around cloud, rather business units can make decisions which fragment skills, data, and management. The taxonomy gives organizations a good framework on what to consider.

Another important consideration for enterprise IT professionals is the degree to which a hybrid-cloud offerings makes it easy to move workloads between public and on-premises platforms, based on "data gravity," compliance, and other performance and ops reqs.

Another key aspect is leveraging my current staff, what's the learning curve, specially when it comes to Infrastructure as Code area. How many different orchestration ways a CSP provides matters (Chef, Puppet, Ansible, Terraform....)

Key attributes buyer look for are:
1. Agility (ease of use)
2. Workforce learning curve (ease of use)
3. Price/performance ratio
4. Breadth of services
5. Openness (APIs)
6. Interoperability
7. Portability enablement (vendor lock-in)

Building primitives (more the AWS approach) vs. building more up more holistic services with defined use cases. Also, looking at where you're adding value on top of cloud services and evaluating likelihood of said cloud vendor growing up the stack to compete with you.

For high value Systems of Record, the choice of cloud is harder. The key is to minimize conversion costs. In general, if the database is Oracle, Oracle Cloud at Customer is likely to be the best option. If the database is Microsoft SQL server, Microsoft Azure is best.

Enterprise IT professionals are evaluating cloud platforms' suitability for "lift-and-shift" and refactoring of HVTAs. Those requirements may be in the context of migrating some or all workloads to public clouds within a hybrid strategy.

If the application is smaller and running on MySQL, the choices are broader, and AWS would be likely to be king

But it doesn't seem that migration requirements are driving enterprise IT users to one public cloud over another, net-net.

had a great discussion recently with @petersmails of @imanisdata discussing Mass Data Fragmentation. Rather than 1 giant database, enterprise often has a dozen or more NoSQL/Hadoop options

Example from our research is Cloud at Customer vs. Azure analysis for Oracle Databases https://wikibon.com/oracle-database-on-premises-cl...

Yes, of course. IMO It's VERY VERY VERY important, is that we see #HybridCloud in two contexts, Hybrid cloud for same workload (here Operations Management matters most), and #HybridCloud for different workloads (here interoperability matters most). Get clarity first!

Somewhat - for truly high value applications, it's not a migration question as much as a "migrate to Oracle/SAP/etc. cloud" (aka the cloud of company building the core product) or "rebuild on top of more native cloud tech". Migration is huge risk.

Many big-data analytics apps are inherently hybrid. Much processing of unstructured data these days is done in public clouds, but the front-end data warehousing, analytics, and apps that derive insights from all that are in on-prem environments.

Most current system move all the data required to one place, and then process the data. As the amount of data grows, this model breaks down because of cost and elapsed time. For a real-time system, moving the code to the data would accomplish more in real-time!

This is a simpler one....but a web/app/db stack on-premises backed up to the cloud with test/dev happening on ephemeral resources. It's a simple approach because don't have to break up the application but could lower test/dev costs and/or have unlimited test/dev.

This is being done at the moment in hybrid applications that connect systems of record with analytic systems. E.g., fraud detection systems.

Examples of Hybrid Cloud have to been in two aspects, 1. Same Business Application split, 2. Different Business Applications interacting. In 1st category examples are:
1. e-Commerce
2. Media and entertainment
3. BI/ML
4. Simulations related use case...

@dfloyer agree... there's a data inertia and time-to-respond and a place to collect/work on data that's always going to play a role. VDI was a perfect example of one size (centralized) doesn't fit all.