Image

Image
from Filip Kamban
Cloud Engineer, from Dübendorf

#knowledgesharing #level 100

Multi-Cloud vs. AWS Cloud Adoption Framework 

As Multi-Cloud IT solution is, according to research, embraced by 93% of enterprises as their strategy it would be good to have it in analysed through the AWS Cloud Adoption Framework lenses, likely the most accurate and comprehensive white paper which explains the right way to transform your ancient business into a modern one. It describes 6 perspectives of the process regardless of the cloud of your choice, goes through all its phases from start to end and explains how to comprehensively reach the goal and achieve the full potential.

ImageImage

I recommend everyone to be clear about their motivation and the benefits of a single or hybrid cloud solution. Furthermore, it would also be good to accept that failing over resources from one to another cloud in the case of outage is not a quite realistic solution at all.
It would be good to be realistic and understand that saving a few dollars here and there on one resource can open-up many unintended and very costly consequences.

Let me just for now discuss a few bumps on the road in no particular order, if you are already or do want to take that way.

Why Multi-cloud? Was it because of …

  • Business reasons and governance?
    • Cost control? Theory says that one of the advantages of multi-cloud is the ability to provide developers and database administrators with a “self-service” experience, the ability to quickly deploy their applications in their cloud environment of choice. Real life often disagrees. Most of the time you don’t need that flexibility and unfortunately, this can also lead to sprawl when an organization loses track of where its applications are hosted or when applications are not being run efficiently. Many have lost many thousands on lost and unneeded resources. Even the billing process itself can become confusing when enterprises use multiple clouds, with each cloud vendor use different billing systems and employing a variety of pricing, fees, reservations, and infrastructure sizing models. Tracing project costs when resources are distributed in multiple clouds and accounts are somewhat difficult.
    • Licence management and discounts will be harder to plan and, in the end, likely less fruitful.
    • It’s claimed that a multi-cloud approach is one way to meet governance requirements for keeping data in the “correct locations.” However, enterprises are ultimately responsible for the security of their data in all of their cloud and on-premises environments, as well as when data is transferred from one cloud platform to another. More clouds mean more work, more problems and more errors.
    • Data Portability can also be an issue. Moving data to cloud is free, but egress is not. Will you bounce data from one to another cloud? Well, that costs money.

  • People?
    • The most efficient – 2 pizza team organization is hardly an option for you. You’ll have probably two or more teams who will likely rival each-other to fight for the best projects etc.
    • As Cloud Orchestration and having everything automated is harder to achieve when everything is different in different clouds, you’ll likely need more developers which will come at the much higher cost enriched with additional complexity then you can save by picking only one cloud.
    • Communication, teams autonomy, change management, planning, agility will all be affected and not in the good way.
    • Additional complexity will make education and training more difficult, not even mentioning the career paths. How much time you’ll need to find and onboard a new member?
    • Overall knowledge about your own software will be lowered. There will likely be no one who would know most of the stuff and who you could always call and who will always find the quick and adequate solution. Instead, many times you’ll hear the sentences like “but it’s not my job” or discussions like cloud A is better than B or similar.
    • Planning will be more important and likely talent fluctuation will be increased. Talent scarcity is an issue everywhere you check. The demand for personnel with mastery of managing specific cloud platforms or multi-cloud environments is high, but the supply is scarce. Enterprises often find it difficult to keep the right personnel in-house to manage a multi-cloud environment and some even turn to managed service providers with multi-cloud expertise to fill the gap which is non-productive work and is utterly unnecessary to one cloud solution.

  • Platform(s)?
    • Interoperability. As enterprises migrate workloads from legacy platforms to the cloud or attempt to move applications or data among cloud platforms, the frustrating interoperability of platforms becomes apparent.
    • Consistency is critical, and you don’t have it. Application updates, scaling, lifecycle management, configurations, operational automation, CI/CD and code can hardly be maintained in singular channels.
    • Is vendor locking your fear? On which level? Product or cloud or invested engineering? Can you avoid it? Can it happen that by avoiding one cloud lock you enter into multi cloud – multi products you use lock? I assume that many will find themselves in that trap. Arguably, the best way to protect yourself against vendor locks is to have Infrastructure as a code with Facade Pattern design handled by an agile team which knows every piece of your software and is capable by themselves to change and move it at any time.
    • Can you provide HA - High Availability with one cloud using multi regions? Yes! So why multi-cloud? Can you fail over from one cloud to another in case of outage? Well, not really. As you go cloud native solutions and move away from simple VM’s by going deeper in cloud technologies through docker flavours and microservices to serverless, clouds tend to diverge more and more in many ways. Terraform can’t fix this issue easily, regardless of what adverts say!

  • Security?
    • As you have Increased Attack Surface, you have increased Security Risk. Every single operation will be more complex, and errors will happen more often, and it will be harder to spot them.

  • Operations?
    • Management complexity is increased. The more cloud environments your organization uses, the more complex the management task becomes. The problem lies in the diversity among cloud vendors. Each public cloud vendor has its own portal, its own APIs, and its own unique processes for managing its environment. Because there is no standardization across public cloud vendors, multiplying vendors means multiplying the management burden.
    • Monitoring one cloud is the challenge, but monitoring two are X times harder. IT teams must deal with siloed vendor tools, a lack of consolidated monitoring across cloud environments and other interoperability challenges that multiply the administrative burden and drive-up cloud costs.

Of course, all of this applies unless you have some special software which can sort all those difficulties and make your cloud journey effortless. Unfortunately, as I have no recommendation to give, it would be good to question the decision again if you really need more than one good cloud, one good team and one good plan. Maybe, me thinking out loud, most of those 93% going multi-cloud should have stayed with just one cloud, the one they prefer or the one their core operation likes the most.

Good luck!

Image

Fully Automated MLOps Pipeline – Part 2

In our last post, we explored training a forecasting model with SageMaker. Now, we’ll complete the journey by detailing how to monitor its performance and automate retraining, ensuring consistent and reliable predictions.
learn more
Image

Fully Automated MLOps Pipeline – Part 1

In the previous blog post we introduced the architecture and demo of a near real time data ingestion pipeline into Amazon SageMaker Feature Store. In this post and the following one, we will present the fully automated MLOps pipeline.
learn more
Image

Near Real Time Data Ingestion into SageMaker Feature Store

This blog post is the first part of a 3 parts series about testing a fully automated MLOps pipeline for machine learning prediction on near real time timeseries data in AWS. In this first part we focus on the data ingestion pipeline into Amazon SageMaker Feature Store.
learn more
Image

AWS AppConfig for Serverless Applications Demo

Wouldn’t it be nice to decouple application configuration from infrastructure configuration and code? This is where AWS AppConfig (a component of AWS Systems Manager) can help
learn more