AWS is better than you.

Today, we will discuss an exciting and extensive topic: "AWS is better than you”. Although a little less forceful, we will see why using AWS managed services is a good idea instead of developing our own solutions.

It is a complex issue that requires a lot of internal criticism and a significant change in mentality.

Given the complexity of the topic, we have decided to divide this article into several posts. In the first post, we will address the issue from a more general point of view. In contrast, in other posts, we will dive into specific examples of managed services at a technical level, exploring their advantages and considering what it would take to implement similar solutions independently.

What is a Managed service?

These are services in which AWS takes care of various essential operational tasks, such as configuration, maintenance, scalability, availability, and security of the service. This approach relieves users of the direct responsibility of managing the underlying infrastructure. These tasks are the user's responsibility in services we generate ourselves, such as the IaaS (Infrastructure as a Service) model.

To have a clearer understanding, here are the definitions of the cloud service models that exist:

• IaaS (Infrastructure as a Service): Provides a virtualized infrastructure over the Internet, where users manage the application layer, operating system, applications, and data.
• PaaS (Platform as a Service): Offers a complete development and execution platform, with AWS taking care of the underlying infrastructure. Users focus on application development without worrying about infrastructure management.
• SaaS (Software as a Service): Provides complete software applications over the Internet. Users access these applications without installation or maintenance, since AWS manages everything.
• FaaS (Functions as a Service): Allows individual code functions to be executed in response to specific events without the need to manage servers. This model focuses on executing specific code without worrying about infrastructure.

In short, a managed service on AWS abstracts the operational management of the infrastructure, allowing users to focus on developing applications and services without the burden of direct infrastructure management.

AWS scale

When evaluating AWS managed services, one of the first things we need to understand is its scale.

Although it is becoming less common, many people still perceive AWS as a giant in e-commerce, instead of considering it one of the largest technology giants in the world.

It is common to believe that we have more IT experience than AWS and have solid knowledge in the On-Premises space that AWS does not have. However, AWS was founded in 2002, which means it has already been in operation for 21 years and launched its first pure Cloud Computing services (S3 and EC2) 17 years ago.

The magnitude of AWS's infrastructure is impressive and has seen extraordinary growth. In 2014, estimations said that AWS managed 1.4 million physical servers distributed across 11 regions and 28 availability zones. However, when comparing this figure to the current 33 regions and 105 availability zones, the scale of AWS becomes even more impressive.

Additionally, when talking about an Availability Zone (AZ), it is essential to remember that a single AZ can host multiple data centers. In a newly launched region, such as the Spain region, AWS commonly has a single data center per AZ and two transit centers where interconnections to the Internet and other AWS regions are hosted through multiple providers.

However, in more consolidated regions, there can be a more significant number of data centers. For example, in eu-west-1, the Ireland region, there are estimated to be more than 10 data processing centers (DPCs). In contrast, in the us-east-1 (with 6 availability zones), there are estimated to be more than 70 CPDs.

The single region scheme is quite impressive compared to the usual infrastructure of most CPDs.

In addition, AWS designs and manufactures its chipsets, networking hardware, protocols, virtualization, and processors.

Reasons to use an AWS managed service

Now that we've delved deeper into AWS's context, let's examine why opting for AWS managed services is highly recommended.

The infrastructure is not pretty

I am passionate about infrastructure. I love knowing how a processor works at a low level, how different services work, and how an EBS works. But let's face it: Infrastructure is ugly. Most people don't like it. He likes it and sees it as a necessary evil for his business.

In this context, managed services come into play, preventing us from having to deal with these problems. In a managed service environment, we don't maintain the infrastructure; AWS provides it automatically, allowing us to focus on our business rather than investing time and effort in maintaining and improving infrastructure.

Additionally, when considering the scale of AWS, the advantage of using managed services becomes evident. They are designed in a way that takes advantage of all the strengths of the AWS infrastructure. To understand the impressive level of high availability that an AWS managed service can offer, I recommend reading the whitepaper AWS Fault Isolation Boundaries, where AWS addresses crucial topics such as the separation of the Data Plane and the Control Plane.

In addition to high availability, managed services, especially in SaaS models, are highly scalable. We can quickly scale to unimaginable limits without providing more infrastructure.

Designing infrastructure with these levels of availability and elasticity is a highly complex task, and this is where managed services prove their worth by simplifying this process and offering an efficient and robust solution.

We don't have to worry about security

We have already discussed security in AWS other times, but what's interesting about a managed services model is that we can delegate responsibility for parts of security to AWS.

You have probably seen the image of the AWS shared responsibility model, but this model is based on IaaS, while managed services are PaaS, SaaS, or FaaS.

This means that the shared responsibility model in a managed service differs, with AWS having more responsibilities than in the previous graph.

That's why I like to use the CIS graph more when we talk about security, which indicates the level of protection depending on the cloud model used (IaaS, PaaS, SaaS, or FaaS).

In the case of managed services, AWS teams handled the security, such as the Ghostbusters team, which we have already discussed. He gave us this excellent session at re:Invent, discussing how they undertook a security event like Log4Shell.

The AWS security bulletin on Log4Shell can be an example, since it informed us about how it was mitigating and solving this vulnerability in all its services.

An event like Log4Shell was complicated to tackle and required much work and time to solve. Applying the appropriate security measures took a long time in some cases, while managed services addressed the problem quickly and without customer intervention.

We don't need to reinvent the wheel

One of the significant advantages of a managed service is using a valid solution that already works, that is tested, and in which AWS supports us.

We often discuss the importance of scale, but when AWS designs a managed service, it does so based on its experience and the experience of its customers.

It is typical for a managed service to improve or even be born thanks to the requirements of one or more AWS customers.

A managed service is created to solve problems for many AWS customers. This is important because AWS dedicates much time and resources to generating managed services and directing them to customers.

Spending design and development time using a functional solution covering our use cases is unnecessary.

We can spend all this time improving our solutions instead of generating existing solutions.

Bad things

Now, we're going the other way. We'll explore the reasons behind choosing not to use AWS managed services.

We will examine these reasons to determine whether they have solid foundations or require reconsideration.

We don't know what we are using

Historically, one of the significant criticisms of AWS managed services has been that AWS is very closed in providing visibility into how a managed service works and what software it is based on.

This has changed in recent years, and AWS gives more visibility to how these managed services work. We have had talks about how different services, such as Lambda, Fargate, DynamoDB, Aurora, etc., work at a low level.
This visibility has allowed us to learn more about these managed services and how they work.

On the other hand, there has also been a change in the naming of the services themselves, prioritizing which solutions they use below instead of having their own naming.

An example would be changing the name of the Amazon Kinesis Data Analytics service to Managed Service for Apache Flink Studio.

Although AWS will not give us all the information about these services, this new visibility into what we use can reduce our reluctance to use a managed service.

Managed solutions have Vendor Lock-In

On the other hand, this opacity existed before, and many people used to talk widely about the feared Vendor Locking, which we have already discussed elsewhere, such as in the Kubernetes post or a specific podcast about Cloud Lock In.

I don't want to go into much detail here, but Vendor Lock-In is something that we cannot avoid. It will exist in OpenSource solutions or even in our own solutions. The important thing is not to avoid it but to control it and be aware of when we have Vendor Lock-In, what it gives us, and how complicated it would be to avoid it.

In many cases, not using a Native and managed solution can be more problematic than the Vendor Lock-In itself.

To avoid the Vendor Lock-In, we generate a solution with its own Lock-In that is more harmful than having opted for a managed solution.

The cost is higher

Usually, a service managed at the infrastructure level is more expensive than a pure IaaS solution.

But this has many points of view. On the one hand, we have to add the cost of maintenance and evolution of our own service, while in a managed service, this cost is included.

We also have to consider the scalability and high availability of managed services; it is useless to compare a service that is not scalable or has less availability than its managed counterpart.

In addition, managed services, especially SaaS models, have a pay-per-use model, which is very interested in terms of expenses since its cost is linked to its use, and we do not need to provision the infrastructure. To begin with, we can try a managed service without the need to make a significant investment. On the other hand, we do not require over-provisioning to cover future demands or even to maintain high availability.

I need to use functionalities that the managed service does not have

This is one of the most complicated and common assumptions because it usually requires self-criticism.

AWS designs managed services for most clients, and we always like to think we are a unique use case, but that is usually incorrect.

Usually, when we analyze a managed service that does not cover some of our requirements, we discard it instead of reflecting on it.

Here, I have to be honest. None of us are as unique as we think, and it is more common that we ask for a requirement that we don't really need.

To give a similarity, I love cars and would love to have one. Ferrari SF90 Stradale. But let's be honest: Considering that I work from home almost every day (Blessed Paradigma Everywhere), that I rarely use the car, and that it is usually with my children, perhaps it is not the most suitable car even though it is a beautiful car.

Well, the same thing happens with managed services. We all want to have a Ferrari, but it is not always the most appropriate and even more so if we consider its cost, which is why it is important to reevaluate our requirements and see if they are real.

When a managed service does not adapt to our needs, we must consider whether our needs are different from the majority or if we are overestimating them.

Conclusion

We recommend always using a managed service; it would be better if it were a SaaS model.

It indeed depends on each solution, but in most cases, a managed service will give us a series of advantages that will allow our solutions to be better in every way:

• Lower cost (Including CapEx and OpEx).
• Greater efficiency.
• Shorter development time.
• Better security.
• Greater scalability.
• Better availability.
• Ease of maintenance.

I have not mentioned something in the article until now. It is an internal criticism that many architects and engineers have: We like complicated things instead of going the simple way.

We often think using a managed service is too simple and does not add value. We tend to look for “better” solutions, but they don't really provide more. Instead of looking for a complex solution, we can dedicate that time to improving our solution using a managed service.