Hosting With Docker And Amazon Web Services
Terms like “Docker”, “infrastructure as code” and “DevOps” keep buzzing around. This article attempts to shed some light on where the advantages in real-life applications are and how they interact.
In a dynamic infrastructure, additional servers are started automatically when they are needed. Two servers may be able to handle the load in the morning at 9am. During the day and with an increasing number of users, additional servers are started. For example, at noon 12 servers may be running. The number of server running corresponds to the number of (active) users. Depending on the application there may be peak loads before noon and in the late afternoon.
During night time there may be little traffic so that the number of servers can reduced to a minimum, for example 2 servers. Why not reduce it to one? For security reasons the application may be in 2 different datacenter locations. If one datacenter has a problem, there is still “a candle burning” in the other.
Cloud services like Amazon Web Services typically charge for servers on a per-minute base. That saves money during low performance time and there is enough power when needed. In the weeks before Christmas there may be 30 servers at peak times. Whatever is required for a steady performance and an excellent user experience.
There is no manual work starting and stopping servers. It also does not follow a schedule. The choreography when additional servers are started or shut down is defined in a so-called metric. The metric defines at which server load additional are prepared to be started and when they actually jump on stage. Cold-starting a new server takes 1-2 minutes. Fine-tuning this metric is the key to steady performance at minimum cost. Once the metric is fine-tuned the environment dynamically manages itself. Regular checks by qualified server operators are advised though.
A user does not notice what is happening on IT infrastructure level, when servers are started or stopped. The application is just “there”.
In the past static environments were most common. Their disadvantage is obvious. The server capacity needs to be oriented on the peak load to be expected. A significant part of that maximum capacity is not used most of the time. A static environment requires 24 hours a day, all year-round payment for peak times.
The biggest enemy of a static infrastructure is success. For cost reasons in many cases a static infrastructure is set up with not too much reserve. As a consequence, any successful marketing campaign (or whatever pushes the usage) means a threat for the infrastructure. The more successful marketing is, the slower the web application gets – or the servers even stop working due to overload. A well-made dynamic infrastructure handles those peaks with ease, no drop of performance and avoids the “success contradiction”.
With dynamic hosting redundancy can be created as well: servers are started automatically in another datacenter if there is a problem in the main datacenter. Regional hosting is another option. For web applications running globally it makes sense to have the respective infrastructure closer to users as internet connection speeds may drop over larger distances. For example, for users in Asia a web application running on servers in Europe or America may feel slow. In that case it makes sense to set up servers in an Asian data center. The infrastructure is typically globally connected.
In case one of the application server has a problem (“hangs”) there are no manual steps required. Using self-healing features the server is automatically removed from service, deleted then installed, configured and put to service again. As said cold-starting a server takes about 1-2 minutes and not noticed by users. That means the hosting environment can repair itself without manual work of server operators and without users noticing any issue.
Updates are very similar to the self-healing process. An update means to simply “tell” the application servers that there is a new application version available. Server by server is removed from service, deleted and installed again, but now with the new application version. In many cases there is no need to show a maintenance page while updates are being installed. Updates can be installed during regular operations.
Dynamic hosting is impressive, easy to explain and the advantages are obvious. But there is more to explore.
Infrastructure as code is less spectacular than dynamic hosting but has equal potential.
To understand the advantages of infrastructure as code let’s have a look at the traditional approach. Not only the servers were mostly static, but also their setup and configuration were mainly manual work.
It might surprise executives but is no secret to server administrators that not very often infrastructure setup and changes are documented properly. In other words, you can make a room full of server administrators very quiet when you ask for an installation and change blog. On the other hand, documenting is time consuming and server administrators are under large pressure especially when they are performing changes. In an emergency situation a proper documentation can be a life-saver. In contrary, each change is to a certain degree driving in the dark without headlights.
Infrastructure as code works best in virtual environments. Opening the box of a new server and plugging the cables cannot be written as code (unless there are robots…). In a virtual environment these steps can be written as code as well as all further setup and configuration work.
In case of a total loss rebuilding the infrastructure might take hundreds of manual steps and several days of work in a traditional environment – depending also on the existence and quality of documentation. With infrastructure as code even a complex server environment can be completely set up and configured in 30 minutes. A “mouse click” is the only manual work required.
A total loss of the infrastructure is of course not a very likely scenario. Rebuilding an infrastructure just explains the general idea of infrastructure as code. There are multiple advantages of having the infrastructure as code.
It is common practice to version control code and of course the code defining the server infrastructure can also be version controlled. Infrastructure changes are controlled, fully traceable, version controlled and easier to revert in case this is necessary. As the risk is lower it makes sense to more frequently fine-tune the environment and have more performance at less cost. Also working in teams on the server infrastructure is easier, as first the code is written, then potential team work conflicts are solved and finally the final infrastructure definition is applied as a whole.
When rolling out new versions it is common practice to test them on a staging (or integration) environment before going live. Setting up this “testing” environment is not only faster and easier, it is also guaranteed that the testing environment is identical. Setting up a staging environment manually so that is identical to the production environment requires long, hard, concentrated (and boring) work. Failover redundancy and backup solutions are defined straightforward and it is easier to see mismatches (false security).
Having the infrastructure as code for dynamic infrastructures is an excellent choice. When servers are no longer required they can simply be deleted, which saves cost and keeps the structure clear. When a new server is started, it is automatically set up and configured cleanly and from scratch within 1-2 minutes. This happens repeatedly and reliably.
In international infrastructures servers are set up in an identical way across the globe making management and control as easy as possible.
A lack of documentation in IT is a significant risk for any company or organization. With infrastructure as code there is a complete, readable and versioned documentation of the environment.
Infrastructure as code is often found in conjunction with Docker. Docker introduces a different thinking of what had been before covered by the term “server”. With Docker an application is split in smaller chunks that run as individual services in docker containers. The docker containers talk to each other so that the application can run as a whole. Having the application dockerized allows for individual and optimum configuration of the Docker containers.
It is no secret, but a standard procedure in the IT to solve larger problems by splitting them into smaller chunks and then connect the individual solutions to what solves the larger problem. Of course, this procedure has its own name: divide and conquer. With higher levels of complexity modularization is the keyword to replace “luck” by predictability and reliability. But modularization it is possible without and therefore this not yet the point, but a precondition for using Docker.
One of the biggest challenges managing server infrastructures for complex applications is finding a match for libraries, base applications and other third-party components. In other words, getting a server ready for the installation of an application is quite often a time-consuming puzzle. As updates are required at least for security reasons the puzzle starts over again with each new version. Beside compatibility also optimizations are a challenge. A configuration setting ideal for module A might slow down module B.
Wouldn’t it be a good idea if every part (service) of the application has its own technical platform? That is indeed the key idea of Docker. The environment for each module of the application is called a Docker container. It may appear inconvenient, but in practical application it is easier to manage multiple docker containers than solving the puzzle. Infrastructure as code allows to efficiently keep control over multiple Docker containers.
The application, or better each module of the application gets bundled with its underlying system. As already seen it streamlines setup and management of the application and its environment. Docker also makes the application independent from the operation system.
This is essentially the same as already known from virtualization. Running a Windows Server as virtual machine makes it independent from the hardware of the hardware – and the respective drivers. The hardware is in fact always the same: the “simulated”, virtual hardware. And this does not change when a server hardware is replaced. Docker combines the advantages of virtualization with the advantages of application modularization.
Having reproducible, independent environment also has great benefits when testing new versions of an application. A 100% identical testing environment just liminates one more risk.
Amazon Web Services uses a technology with is essentially the same as Docker. Using the Docker technology also another way of thinking comes into hosting. It is now rather paying for computing time than renting a server. In addition, the docker containers can be perfectly sized for what is required, which means also choosing a cheaper Amazon Web Services product if that fulfills the needs. Amazon actually uses clothing sizes like S, M, L, XL, XXL, but also products with different features. Finding the right product in the right size for each Docker container can be a challenge but pays off by keeping running costs down where the desired level of performance and reliability is.
Developing web-software and running it on servers have been two different types of work. Technologies like Docker and cloud service like Amazon Web Services introduce another way of thinking about infrastructure. DevOps means that the software developing team takes over some responsibilities from the server administrators. With the infrastructure is defined as code there is a well-structured interface between software developers and server administrators. The software developers have the deepest insights about the application, the modules of the application and how they interact. It makes sense that people “close” to software development define the respective parts of the infrastructure with their knowledge.
h.com develops web software ready for Docker. If necessary, there is no problem running it on a traditional server setup. If you have other requirements, h.com develops your application tailored for your environment.
h.com can also support you in migrating your existing application to a dynamic infrastructure. Amazon Web Services offers a lot of products (maybe call it a jungle). Finding the right ones and setting them up correctly is not always easy. We can support you in setting up an Amazon Web Services infrastructure or completely take over this type of work. We also can support you in dockerizing your existing application. We are, where you need us.
As a part of the DevOps idea h.com also monitors and fine-tunes the infrastructure as well as adjust it if an application update requires it.
h.com creates complex setups with scalability, redundancy, failover strategy and backup solutions. With the experience of complex international infrastructures we can also be the lighthouse in the cloud fog when setting up smaller environments.
Gründer und Geschäftsführer von h.com networkers GmbH