In the fast paced world of technology there is always something to improve in your stack (and there’s nothing wrong with it!). You are probably familiar with the benefits of containerising applications, but let’s quickly recap them. Your app becomes stateless, and configuration is easy to manage. App dependencies are versioned and well tracked, so are your environment variables, so you – or your engineers – can spend time in a more efficient way than figuring out conflicts between environments. It won’t be an exaggeration to say it can help save you weeks of work per deployment. Sounds like a win-win situation.
So let’s assume you have your services already containerised. A natural next question would be: where do you run them? Do you still treat your server as a pet or did you replace it with managed services such as ECS or EKS? Side note: if you’re still wondering what to choose, read our blog post on ECS vs EKS.
You may wonder what’s the advantage of these managed services over what you’ve already been using, so let me give you a few black scenarios. Imagine your container goes down due to the way your application is handling errors. If you simply used docker run on your server, I’m very sorry, but the container won’t be replaced by anything. Your service will be down and your customers disappointed (if that’s a production environment).
On the other hand, you may be more cautious, and protect yourself from that scenario using the docker-compose tool, managing orchestration on your own. Well, it’s not ideal either. You’re limited by the power of your server, as scaling is not that simple anymore. If you want to scale vertically, your machine will be down for a moment. If you plan horizontal scaling, it becomes more complex to manage several machines, and requires some specific routing policies to account for that. Plus, every scaling operation is manual and requires some work.
What’s more, this scenario doesn’t protect you from machines or regions going down. Even when the solution is robust on the application side, if your server goes down, customers are frustrated again. The same goes for availability zones or regional failure, because you don’t have any high availability.
If you’re familiar with cloud concepts, you may think that you actually can solve both problems (autoscaling and high availability) with autoscaling groups (ASG) and you would be correct. But notice three things: first of all, that’s another thing to manage. Secondly, autoscaling isn’t that fast – it requires the launch of a new machine. Last, but not least, you still need to manage your servers and their configuration. You can simplify it a bit by using a tool like SSM, but that’s another thing added to your stack. Can we achieve the same result, but in a simpler way?
Managed container services such as ECS help to orchestrate your containers without the need to manage servers. Well, at least not on your side – AWS does it under the hood. All you need to think about is your task configuration. You can even use fractions of CPU, so you don’t have to buy the whole server. Scaling and high availability will automatically be performed, if you wish to. Plus, if you need to debug, you can access your container shells using ECS Exec.
If you still have an appetite for more, why not automate your deployments with a CI/CD pipeline? Imagine how your developer experience would improve if the application code from the new release would be automatically subject to image build and push to the image repository. To make things even cooler, it could end with automatic deployment. If you’re cautious about automatic deployments (and you probably should be if you’re operating a business), it’s a good idea to have a separate pipeline to deploy to the test environment first and use CodeDeploy blue/green deployments. You can read our article on CodeDeploy, but, in short, it helps you to deploy a separate test group of tasks next to the original one and let you perform tests on them – either automatically or manually – before the final deployment. If you’re not happy with testing, you can always easily rollback!
Sounds complex? Well, it is. But Rome wasn’t built in a day. You don’t have to do it all at once or all by yourself (you can delegate it to cloud experts).
Want an easier route to running your workload in containers, with security, build automation, and scalability designed in? We offer a number of packaged container platforms that provide exactly that.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
