Blog #7: What are Containers?

What are Containers?

Containers are a method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated processes. Containers allow you to easily package an application’s code, configurations, and dependencies into easy to use building blocks that deliver environmental consistency, operational efficiency, developer productivity, and version control. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of deployment environment. Containers also give you more granular control over resources giving your infrastructure improved efficiency. Running containers in the AWS Cloud allows you to build robust, scalable applications and services by leveraging the benefits of the AWS Cloud such as elasticity, availability, security, and economies of scale. You also pay for only as much resources as you use.

Containers and Virtual Machines


Benefits of Containers



Environment Consistency

Containers enable portability and help reduce the organizational and technical frictions of moving an application through the development, testing, and production lifecycle. Containers encapsulate all the necessary application files and software dependencies and serve as a building block that can be deployed on any compute resource regardless of software, operating system, or hardware configurations (e.g., you can run the same container on your Ubuntu laptop and on your Red Hat Enterprise Linux production servers). Whatever you package as a container locally will deploy and run the same way whether in testing or production. This is beneficial for you and your organization because you can deploy an application reliably and consistently regardless of environment. This helps you avoid manually configuring each server and allows you to release new features faster.



Operational Efficiency

Containers can help you get more from your computing resources by allowing to you easily run multiple applications on the same instance. With containers, you can specify the exact amount of memory, disk space, and CPU to be used by a container on an instance. Containers have fast boot times because each container is only a process on the operating system running an application and its dependencies. This reduced footprint enables you to quickly create and terminate applications or tasks encapsulated in a container allowing you to rapidly scale applications up and down. You can use blue-green deployment patterns to rollout new application versions (e.g., using Amazon Elastic Container Service) because the entire application and all its dependencies are contained in an image. Containers also provide process isolation, which allows you to put each application and its dependencies into a separate container and run them on the same instance. There are no shared dependencies or incompatibilities because each container is isolated from the other (e.g., you can run two containers that use different library versions on the same Amazon EC2 instance).

You can also create container images that serve as the base for other images. Operations teams can create a base image composed of the operating system, configurations, and the various utilities they want. Development teams can then build their application on top of the base image. This allows you to avoid the complexities of server configuration.



Developer Productivity

Containers increase developer productivity by removing cross-service dependencies and conflicts. Each application component can be broken into different containers running a different microservice. Containers are isolated from one another, so you don’t have to worry about libraries or dependencies being in sync for each service. Developers can independently upgrade each service because there are no library conflicts.



Version Control

Containers allow you to track versions of your application code and their dependencies. Docker container images have a manifest file (Dockerfile) that allows you to easily maintain and track versions of a container, inspect differences between versions, and roll-back to previous versions.


Cloud is about how you do computing, not where you do computing.

Blog #6 : Serverless Architecture

“No server is easier to manage than no server.”  — Werner Vogels, Amazon CTO

A contradiction? The concept might be causing you come confusion – “IT Infrastructure without servers”?

As is so often the case the answer is “not exactly”!

The term “serverless” in this context doesn’t strictly mean without servers. It means you no longer have to think about them like you once did.

Traditionally the code that makes up applications would be run on physical servers. Until recently a Cloud based architecture would mirror this making use of virtualised servers in place of the physical ones. Several Cloud providers have now started providing services which allow you to upload your code into the Cloud where it can be executed based on events or schedules you specify without having to provision any servers at all. Instead the Cloud provider creates the execution environment for the code as needed.

This means that you no longer have to worry about scaling, capacity and updates. Deploying code also becomes simpler since you there is no need to create virtual machine images anymore. Perhaps best of all though is the fact that you don’t need to have servers running all the time costing you money. You are only charged while the code is executing and many tasks can complete in seconds, or even milliseconds. This means that moving from a traditional server based architecture to a serverless architecture has the potential to generate huge savings.

It is probably fair to say that the front-runner in providing serverless tools is Amazon Web Services (AWS) <>. The main service that AWS provide for facilitating serverless architectures is AWS Lambda <>.

As described above this allows code to be uploaded into your AWS account. The code can then be executed in response to events generated from other AWS services. For example, you could configure code to run in response to image files being uploaded to an S3 <> bucket. This code could produce a watermarked version of the image and put it in another bucket for use by another piece of code. This processing can all be done without any AWS EC2 <> instances being created at all. AWS Lambda code can also be run based upon a specified schedule allowing you to create overnight batch processing jobs for instance.

To make AWS Lambda even more useful however it can also tie in with the AWS API Gateway <> service. In essence this allows Lambda code to respond to HTTP web requests. This means that it is possible to code serverless web based RESTful APIs. In addition, by using S3 to serve static content, entirely serverless web applications and sites can be created.

As an example we recently created an internal monitoring tool where we architected out the use of AWS EC2 instances.   Here we used a range of AWS services in combination with other IT Technologies:


  • AWS S3  <>:  We stored our front end static webpage content and images in an S3 bucket. The pages use javascript to talk to a serverless backend. When clients request static content it is served by S3.
  • AWS API Gateway <>: Using the API Gateway service we were able to create routes to Lambda functions. The Lambda functions are then invoked in response to normal GET and POST requests. In effect the API Gateway routes act like a trigger to run the Lambda functions.
  • AWS Lambda <>: This is the core AWS service for deploying applications using a serverless architecture. We wrote the core components of the application using python and deployed these python components to AWS as Lambda functions.
  • AWS DynamoDB <>:  This managed NoSQL database service is not required for a serverless deployment however we made use of it as it integrates very smoothly with other AWS services. DynamoDB has great flexibility and near infinite scalability.
  • AWS CloudWatch <>: To monitor the deployed AWS resources which made up the application.

Serverless architecture has to be one of the most exciting and innovative concepts to grow out of Cloud computing and has real potential to reduce the complexity, management overheads and cost of running applications.

It also undoubtedly gets you lots of kudos if you can say that your web application is running without using any servers at all!

Cloud is about how you do computing, not where you do computing.

Blog #5 : Infrastructure as code

One of the first things about Cloud computing that really fired up my imagination was the concept of infrastructure as code. The phrase instantly conjured up the merging of two worlds in a very exciting way. As I looked into it more I realised that this concept was clearly one of the cornerstones of the public  Cloud (and of DevOps as well but that is probably best left for another blog post).

This all sounds wonderful but what does it actually mean? To understand this it is easiest to consider the two parts of the term separately. In a traditional IT environment the infrastructure consists of the servers and storage that runs the applications a business uses on a daily basis as well as the networking components that plumb everything together. The code is the software that actually makes up these applications written in a programming language. The infrastructure would be physical but the code would be stored digitally and importantly could be backed up, copied and different versions could be maintained.

Virtual Infrastructure 

In the world of the cloud however the hardware infrastructure components are (from the user’s point of view anyway) virtual. If you need a new server you just log into your account and with a few clicks of your mouse you can have it up and running. The concept of infrastructure as code takes this a step further however and allows the virtual, cloud based infrastructure to be described textually in a way very reminiscent of computer code. This textual description or template can then be used to request the infrastructure.

This has many remarkable and powerful implications. It means that your infrastructure is now reproducible at the click of a button which is great for producing test and development environments that are identical to a given production environment. It removed a large degree of human error from the process. Your infrastructure is also documented in a single location and the templates can be stored, backed up and version controlled in the same way that computer code can be.

How to Achieve It 

To give a concrete example, Amazon Web Services (AWS) <> has a service called Cloudformation <> which allows you to describe your infrastructure using a language called JSON <> (JavaScript Object Notation). You then upload this template and the AWS Cloudformation service works out the dependencies between the various infrastructure components specified and requests that they are created. In AWS terms, this set of infrastructure is referred to as a stack. If you need to modify the stack then you can just make changes in the template and then Cloudformation can work out what has changed and apply them for you.

Infrastructure as code really is a concept that sounds simple and innocuous at first but the more you think about the more you realise how much potential it has to transform the way you work.

Cloud is about how you do computing, not where you do computing.

Blog #4 : Compute

The world of IT infrastructure is essentially made up of storage and compute resources plumbed together with networking equipment. In this post I am going to talk about the compute element of that mix and how public Clouds have revolutionized the provisioning and use of this vital component.

So what are these “compute resources” then? What I mean by this is the things that actually do all the hard work of computing. In the world of traditional IT these would be physical computers sitting in a big room full of cables and air conditioning (often known as a data centre <>). These computers would all have their own CPU’s, memory and disks and would be running operating system software (such as Unix/Linux or Microsoft Window ). These computers would normally be referred to as “servers” (since they provide services to other computers) and one piece of physical hardware would equate to one server.

A revolution then occurred which meant that many servers could run on one piece of physical hardware. This revolution was called virtualization <> and it allowed data centres to be transformed – with fewer physical computers,less power and air conditioning was needed and the provisioning of new servers became a lot more flexible. In the past, if a new server was required then you would have to wait until a physical computer could be purchased, delivered and then set up. With virtualised servers it became possible to provision a new server on an existing virtual host server (and easily get rid of it again once it was no longer needed). Even so there were still limits – the virtual hosts only had a finite amount of memory and disk space available.

The birth of the public Cloud 

Then the public Cloud came into existence and heralded another transformation in the world of servers. Services such as Amazon Web Services <> and Microsoft Azure now allow you to create virtual servers in their data centres. These data centres are vast and have near unlimited capacity to host virtual machines. This kind of service is often known as “Infrastructure as a Service <>” and allows virtual machines to be created in minutes to your specifications. Additionally, you typically only pay for them for the period in which you actually use them. This increase in flexibility provides many benefits including the ability to have powerful servers available with no up-front costs at all – a great boon for start-up type companies, but useful for anyone commencing a new project. It also allows companies to have backup servers in case of a disaster, at very low cost.

To give an example, Amazon Web Services (AWS) provide Cloud based virtual machines via their Elastic Compute Cloud EC2 <> service. The EC2 service has a simple web interface which allows new instances to be created very easily and quickly. There are a large range of different instance types including ones optimised for storage or compute performance. On AWS you pay for EC2 instances by the hour and you can get discount on the cost by reserving them for one or three years.

Virtual machines are one of the cornerstones of Cloud computing and the flexibility, pricing model and convenience that they provide are one of the main reasons why the Cloud is permanently changing the IT landscape.

Cloud is about how you do computing, not where you do computing.

Blog #3 : Elasticity

Elasticity is a fundamental concept underpinning Cloud computing that, when deployed appropriately, can allow you to create highly responsive, reliable and cost effective applications in the Cloud.

In essence elasticity allows the capacity of a given Cloud environment to increase and decrease in response to demand.

As an example of how this might help, imagine that you have a web-site that normally runs happily on a single server in the cloud but suddenly you are “slashdotted”.

What I hear you say?

Your single web-server won’t be able to cope with the massive spike in traffic and eventually collapses in a heap. Using the elasticity of the Cloud however, extra web servers can be automatically provisioned to meet with the demand.  Yes – automatically without intervention or preparation.

After the surge of extra users dies down again, the extra web servers can then be automatically decommissioned.  Since Cloud services are typically purchased on a “pay for what you use” basis then this means that you can match the resources you pay for very closely with what you actually need, based on demand.

Elasticity is usually associated with horizontal scaling of capacity – in other words adding extra servers to an existing set of servers. It is also possible to scale vertically – that is increase the resources (CPU, memory etc.) available to a given server. Vertical scaling is harder to undo when compared to horizontal scaling however, making it less suitable for the flexible increases and decreases of capacity that elasticity attempts to address.

This is all in very stark contrast to traditional IT infrastructure where you would have to purchase enough capacity up front to cope with demand. This would mean that most of that already paid for capacity would typically go un-utilised for lengthy periods of time so that you are more than likely paying far more than you actually require.  You are also reliant on your demand estimate model being correct!

How to achieve it 

In the world of Amazon Web Services elasticity is mainly achieved using a combination of Elastic Compute Cloud virtual servers (EC2 –, the AWS Auto-scaling service ( and AWS Elastic Load Balancers (ELB – It is possible to define an Auto-scaling group which maintains a certain minimum number of EC2 web or application servers and monitors an appropriate metric (typically CPU usage). The Auto-scaling group can then add additional EC2 servers to the group if the metric rises above a certain level. This group of servers can then be registered with an Elastic Load Balancer which distributes requests evenly to the servers. If the CPU load drops back down below a predefined level then the additional EC2 servers can be terminated.

Elasticity is a fundamental concept underpinning Cloud computing that, when deployed appropriately, can allow you to create highly responsive, reliable and cost effective applications in the Cloud.


Cloud is about how you do computing, not where you do computing.