Micro-Services Architecture – Next Generation Application Architecture for Cloud Ready Applications – Part II
Next Generation Application Architecture for Cloud Ready Applications– Part II
The upsurge in micro-services architecture and applications based on it has led to the development of platforms and frameworks that emphasise and foster this application development style. There is not a standard definition of micro-services architecture and nor there are standard guidelines to develop an application around that architecture. There are lot of tools and technologies that help develop applications with micro-services architecture like Container based virtualization with docker, Container orchestration with Kubernetes and platforms like Istio and Apache Kafka.
Istio – Easy management of Micro-Services
Istio provides a complete solution to satisfy the diverse requirements of micro-service applications by providing behavioural insights and operational control over the service mesh as a whole. It provides a number of key capabilities uniformly across a network of services:
- Traffic Management – Control the flow of traffic and API calls between services, make calls • more reliable, and make the network more robust in the face of adverse conditions.
- Observability – Gain understanding of the dependencies between services and the nature and • flow of traffic between them, providing the ability to quickly identify issues.
- Policy Enforcement – Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.
- Service Identity and Security – Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustability.
In addition to these behaviours, Istio is designed for extensibility to meet diverse deployment needs:
- Platform Support – Istio is designed to run in a variety of environments including ones that span Cloud, on-premise, Kubernetes, Mesos, etc. We’re initially focused on Kubernetes but are working to support other environments soon.
- Integration and Customization – The policy enforcement component can be extended and customized to integrate with existing solutions for ACLs, logging, monitoring, quotas, auditing and more.
These capabilities greatly decrease the coupling between application code, the underlying platform, and policy. This decreased coupling not only makes services easier to implement, but also makes it simpler for operators to move application deployments between environments or to new policy schemes. Applications become inherently more portable as a result.
The container orchestration engine Kubernetes was developed by Google and later made open-source. Istio is also developed and managed by Google which is also an opensourced project. Google has been using both of these technologies to develop their applications and provide a unified user-experience.
Apache Kafka – A Distributed streaming platform
Apache Kafka, is another example of robust and well known framework for developing micro-services application. It is totally different from Istio, while Istio focuses more on containers and services, Apache Kafka focuses on service to service communication. Services can be developed independently and their intercommunication can be implemented with Apache Kafka.
Apache Kafka is described as a distributed streaming platform having these capabilities:
- It lets you publish and subscribe to streams of records. In this respect it is similar to a message queue or enterprise messaging system.
- It lets you store streams of records in a fault-tolerant way.
- It lets you process streams of records as they occur.
It gets used for two broad classes of application:
- Building real-time streaming data pipelines that reliably get data between systems orapplications
- Building real-time streaming applications that transform or react to the streams of data
Kafka is run as a cluster on one or more servers. The Kafka cluster stores streams of records in categories called topics. Each record consists of a key, a value, and a timestamp.
Kafka has four core APIs:
- The Producer API allows an application to publish a stream of records to one or more Kafka topics.
- The Consumer API allows an application to subscribe to one or more topics and process thestream of records produced to them.
- The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
- The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.
In Kafka the communication between the clients and the servers is done with a simple, high performance, language agnostic TCP protocol. This protocol is versioned and maintains backwards compatibility with older version. OpenDaylight Project, which is an open-source project backed by The Linux Foundation, is a good example of an application that runs on Apache Kafka.
There are many opensource frameworks for developing and managing micro-services applications. Such applications are influenced by the capabilities of the framework used to develop them which introduces certain amount of dependency. There are applications like OpenStack that are highly modularized applications, but they are developed without using any such frameworks and yet their architecture is inclined towards micro-services architecture.
There are enough tools and frameworks to develop applications with micro-services architecture, but there is no standard practice. From an application perspective, its architecture is greatly influenced by the purpose of the application. That being said, a question that arises is “What applications can be built with micro-service architecture?” The answer is tricky but straight forward, it totally depends upon the purpose of the application. A small desktop application that generates graphs from provided data need not be developed using micro-services architecture. That would not only degrade the application performance but also introduce unnecessary complexity in it. Whereas large applications that have multiple stages of data processing and computations can be developed with this style of application development. Essentially an application that can be segregated into modularized components must always be developed with micro-services architecture. This only applies to applications that involve a lot of remote processing and communication via network protocols. Applications that run on a standalone computer, irrespective of their size and complexity are also not well suited for such development practice.
Best example of Micro-services based applications are enterprise application that run a whole business. Big enterprises like Amazon, Netflix, Uber, Spotify, Walmart, Sound Cloud, etc. are implementing and practicing this Micro-Services style of application development. The tools and technology stack used to develop applications with micro-services architecture demand and robust and flexible IT infrastructure. These applications require to be Reliable, Available and Highly Scalable. Thus, opting for Cloud is the best approach for deploying these applications. Applications that require an increasing amount of resources must be deployed on public cloud, with cloud service providers who provide highly scalable cloud like eNlight Cloud. In case of large enterprises that already have their data centers they can opt for a private cloud solution that not only helps deploy their application but also provide secure and easy management of their data center like eNlight 360.
- Cloud metering and billing exactly how you want it! - July 17, 2018
- The Shift in Cloud Scalability - May 16, 2018
- Micro-Services Architecture – Next Generation Application Architecture for Cloud Ready Applications – Part II - March 20, 2018