As a developer, you value the principles of SOA. You aspire to build applications as a set of consumable services via endpoints. Remember how Amazon used SOA to build the AWS platform and how Google is emulating AWS? However, not all is hunky-dory in the SOA world.
Developing is one thing but running, managing, and maintaining services is a whole other beast. When it comes to the latter, many enterprises still act monolithic. They run and manage applications services as a unit on one or many servers. This approach fails to scale when the services themselves scale or when you need to update and maintain them regularly. So do you lament over the spiking costs and time spent on these efforts or fix the problem?
Recent trends point to microservices as the answer. By definition, microservices are much smaller than services. In fact, Wikipedia says a microservice performs a small task often just one. There are many articles that go in deep about microservices architecture, but we cover an important part here, which is deployment automation. In other words, our daily job.
The self-contained, independent, and reusable principles of microservice architecture help solve the problem of scaling and maintaining application services.
- Self-contained. Microservices are standalone operations that run without requiring other services. That means each runs on its own. You can scale each up or down and replace a service individually instead of updating the entire monolith given the business need and load.
- Reusable. Microservices are self-contained so you can reuse them for other applications and functions. We’re talking of reusing already deployed microservices.
- Independent. Microservices are platform agnostic, which means you can design them independent of infrastructure needs to run anywhere, in any cloud.
So is it easy to shift from SOA-based architecture to microservices? Adopting microservices is not without challenges. To name some, you need to modularize existing software services as self-contained units, you need to configure the microservices to communicate with each other, and you need lots of deployment and test automation.
To address these challenges out of the box, we recommend a DevOps solution like ElasticBox. Take a look at how ElasticBox supports microservice deployments.
1. Modularize self-contained microservices
The box model in ElasticBox wraps each microservice as a standalone component in a service catalog that you can reuse across applications. A script box automates the lifecycle of microservices using Bash, Puppet, Chef, SaltStack, Ansible, PowerShell; a container automates Dockerfile deploys; a CloudFormation box automates AWS resource stacks.
2. Connect microservices via bindings
More microservices means more endpoints to manage. Such endpoints handle REST or other protocol communications over the network. With ElasticBox bindings, network references are as easy to manipulate as programming variables. Want to route database connections to another MySQL service? It’s easy to do. Just point the services to deploy with a different binding value.
3. Deploy microservices independently
Boxes are inherently agnostic. Put infrastructure metadata for CPU, memory, storage, additional disks, virtual networks, firewalls, load balancing, and autoscaling in deployment policies attached to a cloud service like AWS, Google cloud, and more. Policies help you deploy the microservices defined in the script boxes to any platform and cloud. The orchestration engine in ElasticBox interacts with the cloud APIs to auto-provision virtual machines based on metadata from deployment policies. So it’s easy to spin up and destroy microservices on demand without disrupting service availability.
ElasticBox can simplify microservices deployments. For instance the Jenkins ElasticBox plugin continuously integrates ElasticBox automation with Jenkins jobs to test and deliver what the software developments teams build continuously. So the next time you think SOA, think microservices instead.  Feel free to check out how ElasticBox can help.
