Compute Services

Bluemix Service Proxy – Balance, Monitor, and Test Your Microservices

Share this post:

As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.

ServiceProxyIcon_cjs_50x50 By adapting a modern software architecture like a microservice-based architecture based on Containers and VMs instead of a traditional monolithic architecture, many clients can reduce their costs of maintaining and updating their services. However, when moving their services to the cloud, some face major challenges creating large scale architectures.

In a prior blog post, I announced the beta for Service Discovery, which allows clients to automate the registration of their microservices and to easily find them by logical name. This is a foundational service on Bluemix that has helped both our internal and external clients benefit from microservices. As we were designing Service Discovery, we realized that clients would also benefit from a proxy pattern that would allow them to manage their microservices by leveraging capabilities in load balancing, monitoring, and failure injection testing with minimal code.

To help our customers manage their services, we are thrilled to announce the beta for Service Proxy – a vital service that helps you to manage your microservices.

The Traditional Way – Managing Microservices Through Code

One of the earliest questions with Service Discovery is how to balance the load across microservice instances. Service Discovery simply returns a list of instances based on logical name and leaves it to the client to decide which instance to actually call. In many cases, our clients are inserting their own load balancing code whenever they needed to call a microservice to insure that any one instance was not over burdened with requests.

In a similar way, most of our clients are concerned with monitoring the performance of their microservices to make sure they were balancing the load correctly and were writing their own code to record and log the performance of each microservice instance. Without this level of visibility, it would be possible for some microservices to take an exceptionally long time to respond, creating issues for their users.

While writing code that load balances and monitors your transactions is useful, to make a more robust solution, you need to test the failure cases as well. The two most common forms of testing involve injecting either a delay or an explicit failure into the microservice and making sure that the microservice that called it can handle it (see Martin Fowler’s article on the Circuit Breaker pattern).

Taking a step back from these three major issues most of clients faced, we realized that with a proxy pattern, we could handle this for our clients with a simple-to-use UI. By writing the code for our clients, we allow them to focus on the core business logic of their microservices instead of recreating the same code over and over again.

This is what Service Proxy helps you solve – automated load balancing, monitoring, and testing your microservice without requiring code beyond the simple call to the Service Proxy.

Service Proxy Helps Manage your Microservices Without Adding To Your Work

Service Proxy builds on the ease of registration and query built in Service Discovery. Clients use a simple REST API to call Service Proxy with a URL specific to the logical name of the target service. Service Proxy internally calls Service Discovery to retrieve the list of microservice instances and then does a round robin load balancing through that list to minimize performance issues.

Service Proxy also tracks the performance of the call to the microservice and tracks this in the Bluemix logging and metering service.

Service Proxy has a major advantage over other solutions in that it allows you to perform failure injection testing, even in beta. With a few clicks in the UI you can temporarily configure delays and failures through the proxy without altering your microservices. Other solutions lack this key testing capability. In the future we intend to expand this testing to support orderly resilience testing through recipes (via Gremlin from IBM Research). These recipes will take the guesswork out of when you will cause a specific failure and can also help you route failure testing to dedicated failure testing microservice instances. This will significantly harden your microservices to failure, balancing them, and tracking their performance.

Ready, set, go!

For more details on Service Proxy, see IBM Service Proxy for Bluemix documentation here. Follow the deployment instructions to get started using Service Proxy today. While Service Proxy itself is free, it does internally use IBM Containers and IBM Message Hub, which may incur additional charges to your account.

Ready to start improving your microservices? Try Bluemix and Service Proxy today!

For more information on Service Discovery & Microservices

The Service Discovery service has been retired from the Bluemix Catalog.  Please see the announcement blog post [ https://www.ibm.com/blogs/bluemix/2016/11/retirement-of-ibm-service-discovery-and-service-proxy-services/ ] to learn more about the retirement and Amalgam8, our new open source microservice project that will be succeeding these services.

More stories
November 16, 2018

IBM Cloud Functions Adds Support for PHP 7.2

IBM Cloud Functions added support for PHP 7.1 last year, and with the release of 7.2, we are updating! With PHP 7.2 you can ensure better app performance.

Continue reading

November 15, 2018

App Modernization: Assess What You Possess 

Before tackling the job of modernizing your applications, you need to assess your application inventory and how it aligns with business priorities. This will help you determine the best technical path to modernization and the effort and resources required.

Continue reading

November 13, 2018

Infrastructure as Code: Chef, Ansible, Puppet, or Terraform?

Which is the most appropriate Infrastructure as Code tool: Terraform, Chef, Ansible, or Puppet? Alternatively, is the best option to use Terraform for orchestration and one of the others for configuration management?

Continue reading