Interview with Josh Long, Spring Developer Advocate at Pivotal

“The most important benefit of microservices is agility”

JAXenter Editorial Team
Josh Long

No software architect can resist the temptation to talk about their experience with microservices. We launched an interview series with experts who talked about the benefits and challenges of microservices, when people should not use them and what impact they have on an organization. Our fourth interviewee is Josh Long, the Spring Developer Advocate at Pivotal.

In this interview, Josh Long, the Spring Developer Advocate at Pivotal, agreed to talk about his likes and dislikes about microservices. Here are his answers.

JAXenter: Why did you start using microservices?

Josh Long: I was working on a large application in 2007 where different parts of the system were designed and maintained by different groups of people with varying and sometimes specialized expertise. They needed to be able to iterate independently; each service was exposed as a worker connected via messaging.

JAXenter: What is the most important benefit of microservices?

Josh Long: That would be agility. The ability to iterate on a small, focused piece of functionality quickly and to see results.

JAXenter: Have microservices helped you achieve your goals?

Josh Long: Yes, they’ve helped me and Pivotal’s customers too. They also provide a great solution to handling larger workloads and to scale. If you’ve got more than a handful of people working on a codebase, microservices support velocity.

JAXenter: What do you think should be the optimal size of a microservice?

Josh Long: The size is all about team dynamics. If work is saturated by team synchronization and communication, then you will need to decompose the codebase. Agile development methodologies give you a burndown chart or a velocity graph. If this gets slower and less productive, it might be time to consider decomposition to allow individual teams to iterate.

Amazon’s Jeff Bezos calls this “the two-pizza team”: a team small enough (with collocated dev, QA, testers, admins, product management, etc) to be fed with two pizzas. Netflix refers to this as feature teams: a team focused on one feature.

JAXenter: What is the biggest challenge of microservices?

Josh Long: That would be distributed systems complexity.

From where I sit, the best technologies to address these use cases are Spring Boot and Cloud Foundry respectively.

JAXenter: What technology do you think is the most important as far as microservices are concerned?

Josh Long: Any technology that removes the waste in the value chain from product management to production and makes it safe to iterate quickly. DevOps, cloud computing, TDD, agile, etc. are all approaches to remove waste and reduce time to production. Specifically, the things people struggle with include setting up new services that are production worthy (have security, observability, operational features, all built in) and spinning up environments (infrastructure middleware, application servers, DNS, security, load-balancing, scale-up capabilities).

From where I sit, the best technologies to address these use cases are Spring Boot and Cloud Foundry respectively. They also struggle with the implied complexity associated with building a distributed system: how you handle failover, client side load balancing, centralized configuration, leadership election, distributed tracing, service registration and discovery, circuit breakers, and so much more.

JAXenter: How much do microservices influence an organization? Can they leave the organization unchanged?

Josh Long: I don’t believe they can leave the organization unchanged. Microservices are inherently more complex. The whole point is to optimize organization structure by refactoring it. If you have poorly designed teams with communication bottlenecks, your software will suffer.

JAXenter: When should you not use microservices?

Josh Long: There are three cases:

  1. If you’re able to iterate quickly and you have a sufficiently small team where decomposition wouldn’t help
  2. If you’re not already able to benefit from the implied velocity (for example microservices are pointless in waterfall environments).
  3. If you can’t build a distributed system quickly and be truly elastic (WebSphere on a static array of servers misses the point entirely. Microservices are an architecture for elastic clouds.)

JAXenter: What principles should guide you in the division of an application into microservices?

Josh Long: The usual rules apply here. Eric Evans’ amazing book “Domain Driven Design” talks about bounded contexts, for example.

JAXenter: Should every microservice be written in the same language or is it possible to use more languages?

Josh Long: You could use multiple languages, sure, but remember the goal here: velocity. Does fragmenting the organizational expertise in multiple languages help? If so, do it. If it creates more friction than it removes, then maybe not.

JAXenter: What aspects should you take into consideration before using microservices?

Josh Long: These are the four reasons to build what I refer to as a cloud-native system: Can you build a system that benefits from an elastic runtime like a cloud? Can you build a system that is easy to iterate and agile? Can you build a system that tolerates and is resilient to failure? Can you build a system that is observable?

Does fragmenting the organizational expertise in multiple languages help?

Remember, the goal is speed. If you’re not doing CI/CD (which implies understanding testing), then fix that. If you’re not using a cloud environment to automate infrastructure, then fix that. If you’re not able to efficiently iterate between operational and development concerns (DevOps), then fix that. If you’re not doing agile dev, then fix that. These ALL need to happen to truly benefit from microservices.

Thank you very much!

Inline Feedbacks
View all comments