Amazon and Microsoft, the two leading public cloud providers, both offer several dozen web services, each representing a useful application feature or tool that users can invoke through an API. On the surface, these offerings look a lot like microservices. Deeper into implementation, the similarities grow.
A microservice, like a cloud web services, isn’t a part of a single application but instead provides a general resource for applications. Several different applications and many users can access a microservice at the same time — just as they could a cloud web service. A microservice also has the ability to scale in response to load and replace itself if its underlying resources fail, also like a cloud web service.
The only problem with using microservices to build your own cloud web services is that it’s not always clear what gives microservices the desirable properties above. Cloud architects may fail to deploy microservices the right way, and thereby reduce microservices’ value in providing cloud web service features. That’s why planning microservice deployment is critical.
The first step to build your own cloud web services with microservices is to identify the general functions you want to target. Visit the Amazon Web Services or Azure cloud website and review their own inventory of web services — ranging from those related to analytics to security. See what services would be the most useful to your own applications, but don’t fixate on replicating exactly what public providers do — your own needs may be more specialized. Don’t focus on a single application or application group.
The next step is to plan your access. Most application components are designed to be accessed within the applications, not from the outside. Your microservices will have to be accessible to all your applications. Consider creating a microservices subnet to which all your microservices are deployed. Then, expose each microservice API onto your company VPN for general use.
Make sure your microservices don’t create a security or compliance problem. Because microservices are openly addressable and shared among applications, they can lead to information leaks. One solution is to require credentials for microservices access to identify the application or user through a variety of techniques, such as encryption and security keys.
But securing access may not be enough if the microservice design isn’t correct. Between uses, applications often leave pieces of data behind in their storage systems, and this data can compromise security and make it more difficult for microservices to scale. Programmers should develop stateless microservices where possible, and avoid holding any data within the software — called artifacts — when writing microservices.
Once you identify target web services and ensure secure access for your microservices, it’s time to think about portability. Unlike a cloud provider’s web services, microservices are usually hosted in the same way as traditional cloud application components. If you plan on a hybrid or multi-cloud deployment for your microservices, ensure that you can access the microservices no matter where they’re hosted. This may require the maintenance of different machine images, as well as a DevOps model for the various public and private cloud platforms involved.
One of the hidden, but critical, properties of cloud web services is performance elasticity. If a public cloud provider has tools to promote the elasticity of instances through load balancing, use them to build elastic microservices. However, these tools are cloud web services and may not be available from every provider. They also may not be used for private cloud deployments. This makes it essential to lay out the features you’ll need, and how to handle load balancing and scalability, for every deployment model you want to support — ranging from public and private cloud to cloud bursting, failover, and horizontal scaling.
Consider deploying a version of each microservice within each cloud you use. This eliminates the need to scale microservices across cloud boundaries, or for an application in one cloud to have to access a microservice in another. This will help ensure the portability of your cloud web services.
A microservice prepared using the steps above can run anywhere, be used by any application and scale to meet workload performance demands. It’s also possible to write a microservice that contains a cloud provider’s web service, and then use that model to adapt applications for other providers’ web services, even if they’re implemented slightly differently. Careful use of microservices to build your own cloud web services can pay major development dividends for years, and applications, to come.- Cloud Web Services. Contact Musato Technologies to learn more about this service.
You must be logged in to post a comment.