This is part of a series covering sessions at Oracle OpenWorld and JavaOne, 2015
After giving a brief description of what microservices are (using the words of James Lewis: “Applications that fit in your hand”), Daniel Bryant of the software and DevOps consultancy OpenCredo kicked off his instruction on building microservices by explaining some of the core decisions development teams will need to make up front.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The first “up-front decision,” Bryant explained, is picking your deployment platform. Will you use CloudFoundry? Amazon ECS? Kubernetes? Or do it yourself?
The next “up-front” decision comes down to packaging – how are you going to deliver these services? Will you deliver them as straight-up services? Will you use virtual machines, or containers? Will Docker be your de facto container? These are all decisions that will affect your experience with microservices going forward.
Testing was the next big subject for Bryant, who stressed that testers should always keep in mind the “-ilities”: reliability and scalability. For reliability, he recommended the tools ZAP from the OWASP team and the BDD automated security tests available at GitHub. For scalability, he recommended Jmeter, a Jenkins Performance Plugin, and flood.io for cloud load testing.
Bryant also warned attendees to “ensure backwards compatibility all the time,” as it will save you a lot of pain later.
Next, Bryant focused on the importance of implementing strong DevOps principles within an organization in order to find success with microservices. He recommended to introduction of SOLID principles – and older set of object-oriented design principles that, when implemented effectively, should make it easy for a programmer to develop software that is easy to maintain and extend over time. He also stressed the importance of good continuous integration and continuous deployment principles in order to avoid creating problems for developers or app managers down the road.
Bryant made reference to the “Dickerson Hierarchy of Reliability,” during his presentation to establish the importance of establishing a “chain of responsibility” when it comes to fixing a broken application or service. According to this hierarchy, monitoring and incident response personnel rest at the base of the pyramid, while postmortem teams, testing teams and capital planning teams sit at the middle as the next in line when something goes wrong. The developer and the user sit at the top. This way, an organization can establish who to go to when things are going wrong.
“I’ve worked in too many organizations where people are too quick to blame and not take responsibility,” said Bryant, stressing the importance of establishing clearly defined “emergency” roles. “It’s all about the people.”
Another point that Bryant wanted to drive home was the importance of implementing key performance indicators (KPIs) for the business as a whole when it comes to establishing project priorities. He refers to this practice as “symptom-driven monitoring” – an approach that places business needs first.
“Think about what’s important to the business; think about business issues first rather than tech issues,” citing an example where, say, a certain database is down. You must ask yourself – should I fix it just because it is broken, or is it crucial to the business? Bryant suggested using ELK stack as a way to monitor business priorities.
Bryant had these final notes on working with microservices:
- Look at your “microservice platforms”
- The local development of three or more services can be difficult
- Think about your build pipelines
- Testing requires a “paradigm” cultural shift
- Consider your infrastructure carefully to avoid problems
- Plan for inevitable issues
- Try not to create your own platform
So what did attendees think about the session? Greg, a back-end Java developer with a major retailer who attended the session but did not want to give away too much information about himself, said that while he wasn’t overwhelmed with new information, he did learn a few things about “the importance of taking in account in advance how you monitor, how you test…those are things I want to ask my colleagues when I get back.”
Greg added that, when it comes to working with microservices, “we have to go through challenges with DevOps stuff, building the pipelines to make the final images and store them in our refectory repository…and then testing them. For instance, I don’t know how ‘that’ team is doing their QA, I only know how we’re doing our QA with microservices.”