Containers & Microservices

In order to successfully host the internet scale applications organizations are seriously considering migrating to Containers and Microservices. Few companies had containers on their product roadmap in 2014. In 2015 almost every organisation was either testing or evaluating them.

With computes running in hundreds if not thousands and the need to cater to any kind of surge in user traffic organization see the solution in Containers and Microservices approach. Soon Containers and Microservices would become table stakes.

Agility

Being slow is the new dead when it comes to internet scale applications. The ability of an organization to rapidly adapt to market and technology changes is extremely important to the success of the organization.

The Microservices architecture allows one to break things into smaller services which adds to the ability to make changes in response to a bug or a new feature request much faster. These services when developed in containers makes it super easy and quick to deploy on QA or production systems.

Environment deployment times have reduced from 4-6 hours to minutes thanks to containers. Containers are created from an image. Image creation is fast and easy. The whole cycle from development to deployment is drastically reduced giving an edge to companies by releasing features at a faster pace.

Operability

Most of the organizations are scaling up quiet fast and need technologies that would be easy to operate at such a scale. The use of containers holds a promise to ease the whole task of operability as the applications scales out horizontally and elastically. Container is slowly becoming the fundamental & standard unit of deployment.

Portability

Even with VMs shipping code from development environment to production is a problem. VM images have to be converted and transferred both of which are slow operations. Unlike VMs, Containers are not restricted to a specific cloud providers.

Containers provide write once, run anywhere design that improves the portability in a big way. Containers are easy to move as container images are broken down into layers. When updating and distributing an image, only relevant layers are shipped. One can build, ship, and run any app, anywhere.

Cost Savings

With containers businesses can optimize infrastructure resources, standardize environments and reduce time to market. Running containers is less resource intensive than running VMs. Docker enables users to run their containers wherever they please either in a Cloud or on-premise. thus avoiding vendor or Cloud lock-ins. One can move their containers to any Docker host on any infrastructure from Amazon, Google, or Azure whichever is the best for their budget.

Scalability

Elastic (Scaling) is a new normal. Monolithic applications are difficult to scale let alone elastic scaling. The solution is to migrate to microservices architecture. The scaling of a particular micro service is far more easy because if a particular microservice becomes a bottleneck due to slow execution, it can run multiple instances on different machines to process data in parallel.

With the monolithic systems you would have to run a copy of the complete system on a different machine making it far more difficult. With Containers and microservices organization can elastically and horizontally scale their application dynamically in response to the spike in user traffic.

Resilient

With microservices architecture even if a particular service goes down it would not cause the crash of the whole application. Services are up front designed for failure and for the unavailability of other services.

Developer Experience

The developer experience with Docker has improved multi-fold in the recent past. Developers love the experience with Containers as it allows them to package up an application with all of the parts it needs (such as libraries), ship it and run it. The Application that runs in Developers machine works in QA and production without any hassles. A developer machine can run tons of containers which may not be possible with VMs. The same container built for development are also deployed to production.

Summary

While both Containers and microservices have existed independently for a long time they work best when put together. The benefits of microservice architectures are amplified when used in combination with containers. Container-based development are a great option for microservices, DevOps, and continuous deployment, all of which are critical to an organizations success.

Containers can share more context than VMs thus making them a better partners of microservices as it helps to decouple complexity. Docker is available on all modern Linux variants. Many IAAS providers have server images with Docker. There are multiple mature container orchestration engines like Kubernetes, Docker Swarm and Apache Mesos.

Building Scalable Applications

In this blog posts Rahul (rahulamodkar at gmail dot com) looks at key strategies to consider while building highly scalable application.

Introduction

Everyone want to build the next Unicorn whether it is a cab aggregating company like Uber or the room stay aggregating platform like Airbnb. The common thing among these is that these need to highly scalable web applications that are ready to serve millions of users. We will look at some strategies that one needs to consider while designing such applications that are expected to scale.

High Scalability Strategies

Without going into too much details and also not talking about the specific tools, we will look at each of these strategies that can help one develop the scalable application.

1. Cloud

Consider deploying your application on the cloud. The cloud comes with the promise of limitless resources which can help you scale up or down in response to the traffic to your site. Theoretically the cloud can provide you as many resource as you request. The aspect of auto scaling also allows you to pay for only those resource that you end up using.

2. Load Balancing

One can deploy a load balancer that will help you distribute the load to your site into different servers thereby ensuring that not one server is overloaded which could result in it going down. Think of it as a traffic cop that will route the client requests across all servers such a way that no single server is overworked.

3. Content Delivery Network

Deploy the services of Content Delivery Network (CDN). A CDN (Content Delivery Network) is a global cluster of caches that can serve as local caches for static files (objects). The static content files are served from the CDN's caching-node closest to the visitor because the CDN takes the geo-location of the user in account.

4. Design for High Availability

It is very likely that the server on which your application is deployed may go down or in a extreme scenario the entire data centre may be down. To tackle this, think of deploying your application in a more than one geographical zone or data centre. This way when a server or an entire data centre goes down, your architecture be such that the application would simply stop routing traffic to the affected data centre. Also one needs to handle hardware and software failures by adding redundancy to the application design and eliminate any single point of failure.

5. Microservices Architecture

In micro-services based architecture, complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task. In a Microservices architecture the scaling of a particular micro service is far more easy when compared to a monolithic application . If a particular microservice in a application becomes a bottleneck due to slow execution, that particular Microservice can run multiple instances on different machines to process data in parallel. With the monolithic systems the scaling is difficult as you would have to run a copy of the complete system on a different machine.

6. Distributed Cache

A effective distributed caching strategy will improve performance in most of the scalable applications. Especially for read-intensive applications a caching implementation can boost the performance as application processing time and database access is reduced.

7. Database Master Slave

Deploy the Master Slave Database strategy where there is a dedicated powerful server for the writes and much lesser powerful database server dedicated to reads. Such a master-slave replication strategy when deployed in the right scenario lets an application distribute its queries efficiently.

8. NoSQL Databases

Consider using the NoSQL Databases. NoSQL databases have the ability to handle large volumes of structured, semi-structured, and unstructured data. They come with an inbuilt scale-out architecture would seamlessly work with your scalable application architecture.

9. Monitor

It is important that you monitor your application for various parameters so that you can either manually or in a automated way take a corrective action. The parameters that should typically be monitored could be applications, services, operating systems, network protocols, system metrics and infrastructure components. For e.g. monitoring will help you identify the health of server instances and automatically terminate & re-launch unhealthy instances. Monitors the application log files and put in place a process that make the engineers take action on issues identified.

10. Database Sharding

As the data grows one cannot keep on buying ever bigger, faster, and more expensive machines. Sharding as a strategy breaks the application database into smaller chunks called "shards" and spreads them across a number of distributed servers. The "Sharding" approach allows the application to scale linearly at a low cost as the data is distributed to multiple physical nodes and allows parallel data access.

11. Horizontal Scaling

In this Linear scalability approach the job of processing is spilt into multiple pieces and distributed among multiple compute nodes. More nodes can be added or removed in response to the surge or dip in traffic thus auto scaling the application to tackle the workload. If a node fails, the other nodes in the cluster take up the workload of the failed node thus adding fault tolerance to the application.

12. Stateless

It is important that the application is stateless for it to auto scale especially in a horizontal scaling approach. Being stateless, services can be easily scaled horizontally thus improving availability and tackle the surge in traffic by scaling automatically.

13. DNS Lookups

Reduce the number of DNS lookups needed to reach the application pages. This is especially true for those pages where the user expects the page to be high on performance. The less number of DNS lookups on the application pages the better your page download performance will be.

14. Commodity Systems

Use inexpensive commodity grade systems where possible so that if one of the systems goes down it is easy to replace it with another. This approach goes hand in hand with the scale out or the horizontal scaling approach and is more effective in a environment where there is hyper growth in the number of users of the system.

15. Asynchronous Communication

Asynchronous Communication is an integral ingredient in the recipe for scalable applications. In addition to asynchronous communication the application also needs to be developed such that it is asynchronous in behaviour. The problem with synchronous communication is that they stall the entire application’s execution as they wait for a response, which binds all the services and tiers together resulting in cascading failures.

16. Containers

Running containers is less resource intensive then running Virtual Machines thus allowing you to add more computing workload onto the same server. Provisioning of new containers take a few seconds or less, thus the data center can react quickly in response to a spike in user activity. Containers are a cost effective solution. They can potentially help you to decrease your operating cost (less servers, less staff) and your development cost (develop for one consistent run-time environment) which could be a big factor when it comes to scalable applications.