Aditya Sharma's Blog

Micro-Services

Aditya Sharma's photo
Aditya Sharma
·

4 min read

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. Each service runs in its own process. The services communicate with clients, and often each other, using lightweight protocols, often over messaging or HTTP. The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

Benefits:

Microservices give your teams and routines a boost through distributed development. You can also develop multiple microservices concurrently. This means more developers working on the same app, at the same time, which results in less time spent in development. Some of the advantages are:

  • Highly maintainable and testable
  • Loosely coupled
  • Independently deployable
  • Organized around business capabilities

Architecture:

Microservice_Architecture.png

Each microservice is relatively small, easier for a developer to understand, the IDE is faster making developers more productive, the application starts faster, which makes developers more productive, and speeds up deployments.

Microservices have many benefits for Agile and DevOps teams - as Martin Fowler points out, Netflix, eBay, Amazon, Twitter, PayPal, and other tech stars have all evolved from monolithic to microservices architecture. Unlike microservices, a monolith application is built as a single, autonomous unit. This make changes to the application slow as it affects the entire system. A modification made to a small section of code might require building and deploying an entirely new version of software. Scaling specific functions of an application, also means you have to scale the entire application.

Examples of MicroServices:

  • Netflix has a widespread architecture that has evolved from monolithic to SOA. It receives more than one billion calls every day, from more than 800 different types of devices, to its streaming-video API. Each API call then prompts around five additional calls to the backend service.

  • Amazon has also migrated to microservices. They get countless calls from a variety of applications—including applications that manage the web service API as well as the website itself—which would have been simply impossible for their old, two-tiered architecture to handle.

Limitation of monolithic architecture versus its solution with microServices

As we know, change is eternal. Humans always look for better solutions. This is how Services became what it is today and it may evolve further in the future. Today, organizations are using agile methodologies to develop applications; it is a fast paced development environment and is also on a much larger scale after the invention of cloud and distributed technologies. Many argue that monolithic architecture could also serve a similar purpose and be aligned with agile methodologies, but Services still provides a better solution to many aspects of production-ready applications.

To understand the design differences between monolithic and uServices, let's take an example of a restaurant table-booking application. This app may have many services such as customers, bookings, analytics and so on, as well as regular components such as presentation and database..

We'll explore three different designs here - traditional monolithic design, monolithic design with services and Services design.

Microservices build pipeline

Microservices could also be built and tested using the popular CI/CD tools such as

Jenkins, TeamCity, and so on. It is very similar to how a build is done in a monolithic application. In microservices, each microservice is treated like a small application. For example, once you commit the code in the repository (SCM), CI/CD tools triggers the build process:

  • Cleaning code
  • Code compilation
  • Unit test execution
  • Building the application archives
  • Deployment on various servers such as Dev, QA, and so on Functional and integration test execution.
  • Creating image containers

Then, release-build triggers that change the SNAPSHOT or RELEASE version in pom.xml (in case of Maven) build the artifacts as described in the normal build trigger. Publish the artifacts to the artifacts repository. Tag this version in the repository. If you use the container image then build the container image.

Deployment using a container such as Docker

Owing to the design of MicroServices, you need to have an environment that provides flexibility, agility and smoothness for continuous integration and deployment as well as for shipment. MicroServices deployments need speed, isolation management and an agile life cycle.

Products and software can also be shipped using the concept of an intermodal container model. An intermodal-container is a large standardized container, designed for intermodal freight transport. It allows cargo to use different modes of transport - truck, rail, or ship without unloading and reloading. This is an efficient and secure way of storing and transporting stuff. It resolves the problem of shipping, which previously had been a time consuming, labor-intensive process, and repeated handling often broke fragile goods.

Shipping containers encapsulate their content. Similarly, software containers are

starting to be used to encapsulate their contents (products, apps, dependencies,

and so on).

Previously, virtual machines (VMs) were used to create software images that could be deployed where needed. Later, containers such as Docker became more popular as they were compatible with both traditional virtual stations systems and cloud environments. For example, it is not practical to deploy more than a couple of VMs on a developer's laptop. Building and booting a VM machine is usually I/O intensive and consequently slow.

For more information, visit MicroServices

BlogsWithCCMicroservices