Tech - xCloud Architecture (Part 4): At Your Service
"The way to get started is to quit talking and begin doing.", Walt Disney.
Let's start developing the e-commerce platform feature one at a time. Since, services are the centre of the platform, I initially built the basic set of services required, like - product, price, category, search etc.
Building Blocks
Identify the key building blocks of a service. Some of them could be -
- Programming language to be used, in this case it's Python.
- Framework - Flask.
- API Gateway to provide authentication, throttling, etc. - 3Scale.
- Logging provider - Logentries.
- Provider - The provider under the service contains the business logic. I am going to take one service as an example - search. I used two providers - Indexden and ElasticSearch. I will explain in a moment why.
Anatomy of a Service
 |
| All logos are registered/trademarked/copyright of the respective organizations. They are shown in the diagram above for ease of understanding. |
Handling Change
"One eye on the past and the other on the future."
Once you have a service in place, it's always a balancing act. On one hand, the consumers of a service expect stability. On the other hand, there are changes over which we have no control over. And, I had to confront one such change.
In 2013, the search service was using Indexden as it's provider. Indexden is based on IndexTank (that was bought by LinkedIn and open sourced). Unfortunately, Indexden have decided to shut down by end of 2014.
Incidentally, I was also setting up my own ElasticSearch instance in the cloud. My timing couldn't have been better. So, I used dependency injection in the provider to switch from Indexden to ElasticSearch. The public interface (endpoint, request and response etc.) of the search service remained unchanged. This way the client was oblivious to the change in the underlying search engine.
And, this is where the vagaries of the real world come into play. Let's assume that search was a critical and differentiating feature of the platform. Ideally, I would have gone with my own search engine in an IaaS/PaaS environment. But, I couldn't find a suitable provider when I started, so I went ahead with a SaaS offering. Having said that, the search service was designed flexibly so I was able to make a change with no impact to the client.
I will cover in subsequent posts about the logging and monitoring.
Once you have a service in place, it's always a balancing act. On one hand, the consumers of a service expect stability. On the other hand, there are changes over which we have no control over. And, I had to confront one such change.
In 2013, the search service was using Indexden as it's provider. Indexden is based on IndexTank (that was bought by LinkedIn and open sourced). Unfortunately, Indexden have decided to shut down by end of 2014.
Incidentally, I was also setting up my own ElasticSearch instance in the cloud. My timing couldn't have been better. So, I used dependency injection in the provider to switch from Indexden to ElasticSearch. The public interface (endpoint, request and response etc.) of the search service remained unchanged. This way the client was oblivious to the change in the underlying search engine.
And, this is where the vagaries of the real world come into play. Let's assume that search was a critical and differentiating feature of the platform. Ideally, I would have gone with my own search engine in an IaaS/PaaS environment. But, I couldn't find a suitable provider when I started, so I went ahead with a SaaS offering. Having said that, the search service was designed flexibly so I was able to make a change with no impact to the client.
Summary
The search service and provider are written using Python and Flask. All they need is a host to run on. Currently, the service running is on the Openshift public cloud. All the capabilities like API gateway, search engine, logging and profiling are abstracted away. This way, portability of any of these providers or the service itself is quite easy.I will cover in subsequent posts about the logging and monitoring.
Comments
Post a Comment