Micro Services

Microservice architecture, or simply microservices, is a distinctive method of developing software systems that try to focus on building single-function modules with well-defined interfaces and operations. The trend has grown popular in recent years as Enterprises look to become more Agile and move towards DevOps and continuous testing. Microservices are a modern approach to software whereby application code is delivered in small, manageable pieces, independent of others. The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

But the bigger question here is why you'd want to use a microservice-based infrastructure. The goal is, simply put, to deliver quality software, faster. Using microservices is a means to that end, but there are other considerations too. Breaking your apps into microservices isn’t enough, you've got to manage them, orchestrate them, and deal with the data they create and modify.

What can you do with Microservices?

Compared to monolithic apps, microservices are easier to build, test, deploy, and update. Microservices are the answer to the question: how can my business react faster to new demands, rather than being stuck in the multiyear “death march” of traditional software development? Now, different parts of your development team can work concurrently on your products, in an agile manner, and deliver value to your customers immediately.

Agile development methods are more efficient when the final goal of the project is not defined, and the customer wants the development team to react to the changed requirements rapidly and effectively.

When to use the Microservice architecture?

One challenge with using this approach is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application. Using Y-axis splits might make it much more difficult to iterate rapidly. Later on, however, when the challenge is how to scale and you need to use functional decomposition, the tangled dependencies might make it difficult to decompose your monolithic application into a set of services.

Deployment of Microservices

Now that we understand microservices, how are they deployed?

The best way to deploy microservices-based applications is within containers, which are completely virtual operating system environments that provide processes with isolation and dedicated access to underlying hardware resources.

Virtual machines from infrastructure providers like Amazon Web Services (AWS) can also work well for microservices deployments, but relatively lightweight microservices packages may not leverage the whole virtual machine, potentially reducing their cost-effectiveness.

Code deployments can also be completed using an Open Service Gateway Initiative (OSGI) bundle. In this use case, all application services will be running under one virtual machine, but this method comes with a management and isolation tradeoff.

Advantages of Microservices

The advantages of microservices seem strong enough to have convinced some big enterprise players such as Amazon, Netflix, and eBay to adopt the methodology. Compared to more monolithic design structures, microservices offer:

• Improved fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
• Eliminate vendor or technology lock-in: Microservices provide the flexibility to try out a new technology/language stack on an individual service as needed. There won’t be as many dependency concerns and rolling back changes becomes much easier.
• Ease of understanding: With added simplicity, developers can better understand the functionality of a service.
• Smaller and faster deployments: Smaller codebases and scope = quicker deployments, which also allow you to start to explore the benefits of Continuous Deployment.
• Scalability: Since your services are separate, you can more easily scale the most needed ones at the appropriate times, as opposed to the whole application. When done correctly, this can impact cost savings.

Disadvantages of Microservices

Microservices may be a hot trend, but the architecture does have drawbacks. In general, the main negative of microservices is the complexity that any distributed system has.

Here’s a list of some potential pain areas and other cons associated with microservices designs:

• Communication between services is complex: Since everything is now an independent service, you have to carefully handle requests traveling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency.
• Integration testing is difficult: Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur.
• Debugging problems can be harder: Each service has its own set of logs to go through. Log, logs, and more logs.
• Large vs small product companies: Microservices are great for large companies but can be slower to implement and too complicated for small companies who need to create and iterate quickly, and don’t want to get bogged down in complex orchestration.

Scaling of Microservices

As we see through the flown years, the most in-demand approach to project management was the Waterfall approach. It, being a linear and sequential approach, had separately set goals for each defined phase of the project. The entire process of software development was divided into distinct processes, each having its own beginning and end and all of them cascaded to each other in a linear fashion. The latter had its start once the former was achieved and completed. It looked like an ideal methodology at that time and did wonders for years to come. But with the complexities and variations of the IT world on a rising spree, there was a requirement for a change in the typical approach.

X-axis scaling

X-axis scaling consists of running multiple copies of an application behind a load balancer. If there are N copies then each copy handles 1/N of the load. This is a simple, commonly used approach to scaling an application.

Y-axis scaling

Unlike the X-axis and Z-axis, which consist of running multiple, identical copies of the application, the Y-axis axis scaling splits the application into multiple, different services. Each service is responsible for one or more closely related functions. There are a couple of different ways of decomposing the application into services. One approach is to use verb-based decomposition and define services that implement a single-use case such as checkout. The other option is to decompose the application by a noun and create services responsible for all operations related to a particular entity such as customer management. An application might use a combination of verb-based and noun-based decomposition.

Z-axis scaling

When using Z-axis scaling each server runs an identical copy of the code. In this respect, it’s similar to X-axis scaling. The big difference is that each server is responsible for only a subset of the data. Some component of the system is responsible for routing each request to the appropriate server. One commonly used routing criteria is an attribute of the request such as the primary key of the entity being accessed. Another common routing criteria is the customer type. For example, an application might provide paying customers with a higher SLA than free customers by routing their requests to a different set of servers with more capacity.

Z-axis splits are commonly used to scale databases. Data is partitioned (a.k.a. sharded) across a set of servers based on an attribute of each record. In this example, the primary key of the RESTAURANT table is used to partition the rows between two different database servers. Note that X-axis cloning might be applied to each partition by deploying one or more servers as replicas/slaves. Z-axis scaling can also be applied to applications. In this example, the search service consists of many partitions. A router sends each content item to the appropriate partition, where it is indexed and stored. A query aggregator sends each query to all of the partitions and combines the results from each of them.

MICROSERVICES RESCUE WALMART’S AGING SOFTWARE ARCHITECTURE:

The Canadian arm of retail giant Walmart has serious issues with their existing software architecture, especially around Black Friday – for two consecutive years. At its peak, the Walmart site couldn’t handle 6 million page views per minute and ultimately made it practically impossible for visitors to have any positive sort of user experience.

Part of the problem was that Walmart’s software architecture was design for the internet of 2005 which was centered around desktops and laptops. The use of mobile, smart, and IoT devices hadn’t fully peaked back then. The firm decided to re-platform its legacy system in 2012 using microservices and have set a target that by 2020 to be able to service 4 billion connections!

By migrating to a microservices architecture, Walmart identified that:

• Mobile orders increased by 98%
• Zero downtime on Black Friday and Boxing Day (Canadas Black Friday)
• Conversions increased by 20%

Other Known Uses

Most large-scale websites including Netflix, Amazon, and eBay have evolved from a monolithic architecture to a microservice architecture.

Netflix, which is a very popular video streaming service that’s responsible for up to 30% of Internet traffic, has a large-scale, service-oriented architecture. They handle over a billion calls per day to their video streaming API from over 800 different kinds of devices. Each API call fans out to an average of six calls to backend services.

Amazon.com originally had a two-tier architecture. To scale, they migrated to a service-oriented architecture consisting of hundreds of backend services. Several applications call these services including the applications that implement the Amazon.com website and the web service API. The Amazon.com website application calls 100-150 services to get the data used to build a web page.

The auction site ebay.com also evolved from a monolithic architecture to a service-oriented architecture. The application tier consists of multiple independent applications. Each application implements the business logic for a specific functional area such as buying or selling. Each application uses X-axis splits and some applications such as search use Z-axis splits. Ebay.com also applies a combination of X-, Y- and Z-style scaling to the database tier.

Summary

So, there you have it, an overview of Microservices architecture. In this blog post, we’ve looked at microservices architecture, we covered the key concepts, the benefits this architectural design pattern can bring to the enterprise, and how it can help software development professionals better structure their products.

We’ve also outlined the main components of an application that adopts a microservice architectural pattern and give you some ideas as to why you might want to introduce microservices to your project. In case you do, it’s best to hire expert developers capable of building an exceptional product.

Read more blogs here