When deploying or moving your application or services to the cloud, you can choose between AWS managed services or a self-managed scenario where you manage everything on your own. This is a tough choice, though. At first glance, it seems much more convenient to have all underlying services managed by a service provider, but with this approach, you risk losing full control over your application. On the other hand, greater control equals greater responsibility.
So which approach should you really go for? The convenient and no-hassle fully-managed service, where you hand over some authority to a provider, or the self-managed one where you invest more effort in the deployment in return for total control? Before you decide, why not learn more about these two options.
First of all, let’s get one thing straight: from the technical standpoint, services fully managed by AWS don’t differ that much from the ones you manage on your own. There is always a server at the bottom.
In some cases, when you configure an AWS managed service, you still can see and define the underlying EC2 instances. Take Amazon RDS as an example; in here, you specify EC2 details when launching a new database instance:
Other services, for example Amazon Lightsail, won’t allow you to choose particular EC2 instances directly, although they still use them. In such a case what you can define is the computing power.
There is also another type of AWS-managed services, such as Lambda, which doesn’t disclose EC2 instances at all. You can only select the amount of memory needed, and the CPU will be allocated accordingly.
Although you can’t see any server, certainly there is one running underneath. Lambda will also deploy containers on that server.
There is no reason why you couldn’t launch an EC2 instance and run similar services on your own. You can install your own database, container services or anything you wish, whatever can be launched on an EC2 Linux or Windows instance. The sky is the limit.
Fully-managed resources are convenient and easy to manage. You don’t have to worry about backups, patches and fixes. AWS takes care of it all, and you can even choose a preferred service window for such tasks.
What about resource control?
Some people question the level of control offered by fully-managed services. But in fact, although you can’t manage underlying resources such as EC2 or operating system, you still can control the resource itself. Let’s take a look at Amazon RDS.
By using DB Parameter Group or DB Cluster Parameter Group, you gain a high level of control over your database.
The same applies to every AWS-managed resource. You retain control over a service but not over an operating system or virtual instances underneath. That’s actually quite handy as AWS relieves you of the administrative burden, while you can still set up the service according to your needs.
High availability included in the package
Last but not least, let’s not forget about high availability. When you choose an AWS managed service, you don’t need to worry about redundancy and failover. It all falls on Amazon.
Usually, high availability is handled behind the scenes; you only choose the region where you want to run a service and Amazon takes care of availability zones, failovers, and so on. This applies to S3, for example. In the case of other services, you can choose the preferred availability zone and decide if you want a Multi-AZ deployment. This is how Amazon RDS works, for instance.
So it seems like using services fully-managed by AWS is very convenient. You may wonder why anyone would choose a self-managed service?
By self-managed I mean a service that is your responsibility from A to Z. For example, in such a service you launch an EC2 instance and run all services you need inside of that instance. You’re entirely responsible for patches, fixes, backups, high availability, software versions, dependencies, network infrastructure, security, and so on.
Why would you choose all that administrative hassle over the easiness of fully-managed services? The magic phrase is total control.
Scenarios for self-managed services
With full control over a deployment, you can prepare any environment to exactly match your needs. If you require specific software versions, deployment and management of your environment on your own may be the only option.
Another use case for a self-managed service may be a migration of your application to the cloud. It’s often much easier to launch EC2 instances and move your environment one to one, keeping the existing configuration and software dependencies. Even if you use Docker containers, it may be easier to install Docker on EC2 and move your containers to it than to learn how to use EC2 ECS service. If you have an application environment configured for queuing with Redis, you may prefer to keep it this way rather than to use SQS. Refactoring the application may be hard, and it’s easier to keep things as they are and perform a classic lift and shift of the application.
Sometimes it also may happen that a fully-managed service offered by AWS does not satisfy your needs and you have to provide a similar service on your own. Let me give you an example.
You need a document store, and you would like to use DynamoDB, but unfortunately, it does not support C++ as a programming language and cannot handle server-side scripts. You would consider using MongoDB then, which delivers what you need, but it’s not provided by AWS as a service. The only option to use it is to launch the EC2 instance with MongoDB installed.
What about the pricing?
We should also mention pricing here. Typically, fully-managed services would be cheaper than self-managed ones. However, it’s not always the case. For services paid per use, it’s usually true, but for services leveraging EC2 instances underneath it may not be so, and you should always calculate the price individually. For instance, in theory, it may be cheaper to use EC2 instances instead of RDS with the same computing power. However, when you calculate the cost of managing EC2 on your own, the overall bill may turn out higher. Once again, to compare the costs, evaluate them on an individual basis.
Fully-managed vs self-managed – what works for you?
As is often the case, it’s hard to identify the better option, as the choice is driven by your particular needs. Overall, a rule of the thumb may be that when you’re migrating an existing application or environment to the cloud, you may prefer self-managed environments. They give you more control and flexibility than fully-managed services, especially when it comes to troubleshooting. They’re also much easier to debug, as you have full access to the system logs, and you can see what’s going on under the hood.
For new applications, however, you should consider using fully-managed services. If you are designing your application, you can choose which technologies you will use and adapt the application to a relevant option offered by the cloud.
Ready to make the decision? I hope this short article has helped you make up your mind.