An overview of how to take existing code from an application and evolve it into a cloud-based service hosted by IBM Bluemix.
In my previous article Starting the evolution to microservices (using the Plants By WebSphere sample), I looked at how the WebSphere Application Migration Toolkit could be applied to an existing monolithic application in order to start identifying candidate microservices. Using the Plants by WebSphere sample as a representative application, an image service was identified.
This article presents an overview of how we can take the existing code that serves the images used in the application and transition it through a series of evolutions into a cloud-based service hosted by IBM Bluemix.
Why start with the image service?
The tooling identified several potential services but there are a number of characteristics that are useful to look for when deciding which services to start with. These are:
- Static content: Static content can indicate that there is little or no business logic and likely no update mechanisms. This simplicity means that you can test out infrastructure and other changes without having to worry about separating complex internal processing and interactions.
- Not business critical: I will cover the fact that you will need to code for failures in a later article but you should assume, at some point, that a given call to a microservice will fail. This is even more likely in a evolutionary scenario where you are starting to introduce microservices into your organisation. Starting with services that are not business critical will allow you to learn, refine, and evolve your code and procedures, whilst still maintaining a required level of service.
- Proprietary code: Will the microservice contain intellectual property or proprietary code that has value to you? If it does, this may not be the service to start with as you start to push it to different services and possibly externally to your organisation.
With these in mind, the image service provides a good starting point as it is static content with no proprietary code. If it fails the application can continue to function and be used by customers.
The evolutionary journey
The diagram below shows a series of evolutionary stages for the Image Service. These are not intended to be prescriptive, but to give an idea of how we intend to evolve the image service from being closely coupled to the monolith, all the way to the cloud.
- Identify a service using functional or technological decomposition.
- Create a new service that wraps existing functionality. Data sources are still shared and the monolithic application has direct knowledge of the location of the new service.
- The service publishes its location to a service registry, which the monolith subsequently queries. The service now has its own data and is responsible for maintaining it.
- The service is now hosted in the cloud, potentially freeing up local resources and benefiting from the cloud infrastructure facilities, such as instance scaling and metrics.
This article has looked at the criteria by which candidate services can be assessed in terms of shaping the priority in which they can be evolved. In particular, it has shown why the image service is a good candidate for a first service and presented a series of evolutionary steps that it will go through.
The next article in this series will look in depth at ‘stage 2’, creating a new service, and show what new code and artifacts will need to be created. It will also cover something that is frequently overlooked: what alterations will need to be made to the monolithic application in order to make use of the new microservice.