Application architectures are evolving from the era of large monoliths to a more distributed design based model. One of the key initiators of this movement is the advent of cloud computing and the ability it brings in terms of handling ever increasing scale. When an enterprise primarily soaked (people and processes) with the model of building and managing monolithic applications, the journey to build new distributed systems requires re-learning some of the older design techniques and adopting some new patterns. As part of this, I will detail certain architecture concerns that become prominent when moving to a distributed model of application

• Scheduler/Orchestration management – From managing 100s of instances to managing 1000s of instances require the ability to orchestrate/schedule service instances/containers across hosts in a seamless manner. To handle increasing scale, workload scheduling/orchestration is a key ingredient of distributed system. Products like Docker Swarm, Kubernetes, Mesos, Marathon etc are some of the leading products in this space 
• Service Discovery/Registration – As the container based services go up and down, there need to be mechanism to register/unregister the services along with the mechanism to discover the service end points at run time. Products like Consul, Zookeeper, etcd, Confd, Eureka are some of the leading products in this space. Most of these products support load balancing of the incoming traffic across the service instances. 
• System State Management / Cluster Management – As the cluster grows, there is a need to manage the system state of the cluster. What are the SRV for each of the services, how many instance, on what hosts, what is load etc. To manage this, there is a need for cluster management that keep track of the system state. Products like Docker Swarm Agents, Kubernetes Nodes/Masters, Mesos Slaves, Containership etc are some of the leading products in this space 
• Data storage – the container storage is ephemeral, which means the any data that needs to be retained beyond the container lifecycle need to be persisted outside. Projects like Docker Volume Plugin, Flocker, Kubernetes Persistent volumes etc are some of the key products 
• Network – with each of the containers running different processes, there is a need to manage and at time isolate which container services can access which other services. Multiple containers are running on same host sharing the network resources might require security groups to be created for container isolation. Similarly, containers might want to discover services that are hosted across hosts and need simple model to access those. Products like Flannel, Weaveworks, Calico are some of the products in this space. 
• Monitoring/Auditing/Logging – With 1000s of containers running, monitoring/auditing /logging each of the containers become a tough problem. Data/Logs need to be pulled from each of the container for analysis. Products like Loggly, Fluentd, logentries, datadog, ELK stack are some of the key products in this space. 

Besides this, other factors that need to be considered are Container OS and Container Runtime when architecting a distributed application. Other factors like application runtime, deployment management, DNS, Security, SSO/OAuth, API Gateways, Circuit breakers, Performance/Scalability Patterns etc still need to be handled. In your experience, anything else that is a key architecture concern for distributed application, please do share.

This post originally appeared at www.techspot.co.in

Microservices & Containers - Docker Bangalore Meetup #12 from Aravind Ajad

This post originally appeared at www.techspot.co.in

With the advent of micro-services, the application design paradigm has undergone a major shift. The days of developing monolithic applications are over. We are bringing in the principles (read SOA) hereto the preserve of applications or system integration space into the application development world.

General steps for solution architecture are –

• Break down/decompose the application into functional areas. These functional area’s provide us the with the bounded context
• Within the functional bounded context, design/define your micro services
• Functional areas talk to each other over micro services or use some kind of event queue models 
• Each of the functional areas only expose services to be consumed by the application 

Since the micro-services are consumed within the application, the need of ESB is not there. There is no message transformation or mediations required. But service discovery & load balancing of service instance still need to be done, new tools have come up (e.g. Netflix Eureka)

Now from the design perspective, you have the service identified, exposing endpoints.

Qs comes, who will do the orchestration of service invocation and aggregation of data from multiple services? 

Where does the intelligence lies ?

Options

• Server Side - Create an aggregator service that internally invokes other services (across functional domains) and aggregates the results. This aggregator service is invoked by the application presentation tier
• Presentation/Application Side – If you implementing JSP or server side view creation, the presentation tier can perform the orchestration across the services and aggregate the data. One can use Lambda/Futures to implement non blocking call model also
• Client Side – In this case, the invocation of services and aggregation of data happens at client side. The UI is composes of multiple widgets, which call up individual services and aggregate the response on the client side

Where should you intelligence lie?

There is no correct answer, depending on the use case, different options can be applied. One can also apply multiple options within the same application depending on the type of the client to be supported or at times, you do not want to expose individual services and an aggregator service might be better.

This post originally appeared at www.techspot.co.in