Reactive microservices for enterprise systems

The O’Reilly Podcast: Markus Eisele on the benefits and challenges of implementing a microservices-based architecture.

By Brian Foster
June 8, 2016
Architecture framework. Architecture framework. (source: Pixabay)

In this episode of the O’Reilly Podcast, I sat down with Markus Eisele, developer advocate at Lightbend. Eisele and I discussed the inherent difficulties in developing distributed systems, how reactive principles enhance microservices, the new reactive microservices framework, Lagom, and open source’s influence on enterprise development.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Here are a few highlights from our conversation:

The challenges around building distributed systems

If you compare the traits of microservices, if you think that through a little bit more, it’s not just putting it up in your framework and making it work. It’s not just using another programming approach. Having a microservices-based architecture actually requires a hell of a lot of things. You need to think about your organizational and methodology capabilities. You need to think about 100% automation of everything, including tests, the production setting, continuous integration, and continuous delivery.

You need to be aware of distributed systems and how they react. You need to have a really good idea how to do simple things like service discovery. Just imagine 30 services talking to each other. It’s super hard, even with a small number of services, to actually discover them at the right time with the right version. You also need a data center that’s capable of running all those teensy little services.

The relationship between reactive and microservices

I think what blew me away and hooked me personally with the whole reactive microservices idea is that reactive technologies basically always thought in terms of microservices. Look at something like actors, for example. One actor could easily be a microservice. It’s been fulfilling — all the requirements that came out of the first experiments by companies like Netflix since very much day one, and there are a couple of others, like Haskell. There are ideas in the reactive programming world/community that definitely fulfill all the requirements that we want to see fulfilled from microservices-based architectures.

Easing the barrier to entry with Lagom

I really like the approach. It’s not millions of APIs that you have to learn. The very opinionated approach takes away a lot of the complexity, a lot of the pressure on the individual developers to learn the whole universe of new goodies in reactive programming. Yeah, it’s exactly what Lagom means, probably, because Lagom, it’s a Swedish word meaning just the right amount or the right size, and I think that’s just a perfect description of what Lagom tries to solve.

Seriously, please never forget, distributed systems are hard, but they are possible. Having something that takes all the heavy lifting off you to pre-glue all those individual components together let’s you implement a really great microservices-based architecture while still flattening your personal learning curve as a developer.

Open source and enterprise development

I’d like to see a lot more people developing a giving approach to open source. Personally, that means a lot to me because this is literally where I started out my career in open source, by starting to contribute German translations to an open source project. It was simple guides and stuff that I could actually do in my evening hours, so it wasn’t a big deal for me. But I learned to appreciate working in that setting. It’s been fun to communicate with all these people. Seeing my guides and translations out there actually made me proud.

I really would like to see many, many more enterprises realizing that open source is not a one-way street. It goes in both directions. If the open source community is providing a great framework that you want to use, then there’s definitely a great chance for you to return a couple of favors like sharing your experiences with that app running in production. File feature ideas, feature requests. Maybe even send a developer to do it. Project teams could definitely help in developing those open source projects.

I personally believe that open source is the core, and we all wouldn’t be where we are today if everything that we would have handled would’ve been closed source, like back in the days of Visual SourceSafe…but even Microsoft is changing.

Lightbend is hosting a survey taking a closer look at how cloud architectures, containers, and microservices are being adopted by enterprises, and how choices made in development are defining architecture choices. For each completed survey, Lightbend will donate to a charity—#yeswecode, SeniorNet, or Mouse, which you can select at the end of the survey. Take the survey.

This post and podcast is part of a collaboration between O’Reilly and Lightbend. See our statement of editorial independence.

Post topics: Software Architecture