BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
One topic certain to be widely discussed at the 2016 JavaOne Conference in San Francisco this month is microservices and the race to cleave large, monolithic applications into smaller pieces that each perform a single task. If you're not already designing new systems as a bagful of discrete microservices that you weave together into a larger application, the time has come to get on board lest you be left holding that bag.
On Wednesday, Sept. 21, from 8:30 a.m. to 9:30 a.m., and again on Thursday, Sept. 22, from 11:30 a.m. to 12:30 p.m., Bert Ertman, a fellow at Luminis in the Netherlands, is presenting "Microservices for Mortals," a session that delves into the benefits -- and the pitfalls -- of employing a microservices architecture. A frequent speaker worldwide on Java and software architecture, he was awarded the coveted title of Java Champion by an international panel of Java leaders and luminaries. He spoke with SearchCloudApplications about his session and why microservices are vital for developers.
Many businesses are not yet ready to jump into a microservices architecture. Can they still leverage the concept of microservices to improve their ongoing application development efforts?
Bert Ertman: There are important architectural goals and principles of the microservices architectural style that represent a higher architectural order. These include modularity and single responsibility pattern to name two. Whether you claim to do microservices or not, I think striving for a more modular application architecture enables many good things in general.
Microservices and containers go together. How can developers use them together to maximize the power of each?
Ertman: Containers can be used without doing microservices and microservices can be used without container technologies, but they complement each other quite nicely. When people talk about "containers" they may think of Docker, but to me it is a more generic term where we use an isolation mechanism to run a service or application. The more isolated that mechanism is, the fewer dependencies there are to the underlying infrastructure. When it comes to running a Java service, a container can just be a runnable JAR file or it can be a Docker container where you have both the functional piece (service) and all of its infrastructural requirements such as a (Java) runtime, service discovery agent, and other things in place. A container can also be anything in between, ranging from a runnable JAR file, to container technology, to virtual images running locally or in the cloud.
Is it prudent to re-architect legacy monolithic apps for the cloud by leveraging a microservices architecture and containers, or are developers better off building something entirely new?
Ertman: If you have the luxury of a startup or a greenfield, and you have your DevOps and solid CI/CD [continuous integration and continuous deployment] practices in place, I would say that you have an excellent climate for microservices. But converting a big monolith into a bunch of microservices might, in practice, be a lot harder than the theory sounds. You should separate means and goals. Breaking up the monolith can be useful to make it more modular. As professor Edsger Dijkstra put it a long time ago, modularity is the higher order architectural concept that you're after.
Does that mean a bad monolithic application inevitably leads to a collection of microservices that perform badly?
Ertman: If your current monolithic application is a piece of crap, by breaking it up just to do microservices chances are you will end up with multiple smaller pieces of crap. Therefore, you should distinguish between breaking up a monolithic application to fix technical debt versus breaking it up to accommodate changes in your business model. Microservices mostly apply to the latter. Just 'strangling off' services from a big monolith will not suffice. In most cases it means to completely re-architect the application because it will require changes in terms of service granularity, communication protocol, underlying infrastructure, et cetera. This is a big investment and you should determine whether it will be paid back further down the line.
To evolve an architecture into something that has business agility there needs to be a clear understanding of how these pieces of software align with other pieces of software in the landscape and who is responsible for them. Simply introducing this to developers doesn't make it work. It requires change on multiple levels of the organization and if you forget to include certain parts in the change process, it will slow down or eventually break the entire process.
This gets us into aligning the microservices architecture with the organization. Why is that so difficult?
Ertman: If people think that microservices is the mandatory next step for everything, they will be in for a really bumpy ride. If you start breaking down everything into small pieces without having a clue about what you are actually doing, you will be causing mayhem and destruction to your architectural landscape.
You say failure always happens. When it comes to app development, where does the idea or use of a microservices architecture go off the rails?
Ertman: The first thing to realize about microservices is that it is all about distributed computing. With so many moving parts there will always be something that breaks. Leveraging tools and techniques to do distribution and asynchronous programming models was never easier than today, but can you also wrap your head around those things? Understanding, debugging and solving issues are exponentially harder in a distributed environment than in the traditional world of running everything in a big application server. My key message is to explicitly design for failure from the start and treat as a fact of life that things break. Make sure you are prepared and have your alternatives ready, both in code and on the infrastructural level.
What is the one thing developers should do today?
Ertman: Educate yourself. Microservices is an architectural style that is still relatively young, comprised of a number of tools, techniques and practices. There is no single source of truth. Whatever you do, don't fall into the trap of listening to just one vendor's version of the story. Also don't just blindly follow self-proclaimed de facto standards. The convergence toward a microservices architectural style does not start at the technology level; it requires organizational change.
Five steps to microservices happiness
Microservices and the cloud: Separate and distinct
What is the best language for microservices development?
Simple rules for creating a .NET microservices architecture