Service Virtualization

 View Only

To Share, or Not to Share: Service Virtualization and Microservices

By Anon Anon posted Jul 06, 2015 11:05 AM

  

Microservices are individual units of executable code that work within a limited framework. They are extremely useful when placed within an architecture of numerous microservices. On June 24th, 2015 I attended a webinar titled “How to Share Share-Nothing Microservices,” hosted by Jason Bloomberg, the President of Intellyx, and Scott Edwards, Director Product Marketing for Service Virtualization at CA Technologies. The webinar explained how to use microservices to your advantage in order to deliver products that are competitive in the application economy.

 

The title of the webinar seems a little strange, until one hears how Bloomberg describes the functionality of microservice architecture. He describes the microservices as parsimonious, or extremely cheap or precisely rationed. He uses this to mean that each microservice is as small as it can be without sacrificing functionality. They will perform a single task, and do so effectively. The “share-nothing” concept comes in when we discuss the capabilities of the microservices. Each microservice is small, but still maintains its own code, runtime, OS, and data cache. The data caches should not be shared between microservices, because the instances of the services are constantly changing. This limits co-dependency.

 

In order to take advantage of this, one can use containers. The microservices are meant to have changing scalability, and the containers enable this. The containers then lead to the introduction of virtualization.It might seem that with microservices running in containers we should be all set for the new world of application development, but there is still more to consider. The pain that comes with needing all your services up and running to actually test a single service doesn’t go away with microservices – it actually grows exponentially. Dividing your services into smaller chunks introduces the potential for more dependencies/communications between services to manage.

msev2.png

To resolve this, we introduce Service Virtualization. Service Virtualization addresses the dependencies between microservices in pre-production allowing you to test sooner, faster, and more thoroughly. It’s no longer necessary to activate each microservice and its associated data if virtualization is used. The “container engine” facilitates virtualization rather than guest operating systems. The engine supports all of the containers, which makes the entire process much more streamlined.

 

It is important to remember that containers and microservices are well paired, but not mutually inclusive—you can use one without the other. However, the advantages are numerous. Containers give lightweight, rapid scalability and elasticity. The environment created using containers allows one to keep track of everything and integrate services without creating dependent data caches.

 

The benefits of microservices are huge from a product delivery standpoint. Scott Edwards laid out several compelling statistics from CA Technologies studies. Application economy leaders, who take advantage of these processes, have experienced 106% revenue growth and 68% higher profit. Developers are only coding 50% of their working time because they are waiting on other teams, which service virtualization alleviates. There are teams who have implemented service virtualization that were able to increase testing ability by a whopping 90%.

 

What has your experience with containers and microservices been like?  Have you had more testing concerns in this environment? Will you implement share nothing microservices into your application delivery process? Sound off in the comments.

 

To access the full webinar, click here.To read more about this topic, click here.

0 comments
0 views