How Enterprise PaaS Can Add Critical Value to Microservices

By Atos Apprenda Support


When building loosely coupled cloud apps, microservices are today’s preferred pattern. James Lewis and Martin Fowler wrote the seminal introduction, and the concept has been disseminated widely since. While Lewis and Fowler’s entire post is a fantastic read, one specific requirement stands out: microservices must favor “smart endpoints and dumb pipes.”

Essentially, the smarts should be in the app components, and the communication between those components must be as simple as possible. Without that requirement, architectures will bloat and become monolithic. When asked, “How does your PaaS support microservices?” most enterprise PaaS vendors offer little more than deployment agility. While agility is an important piece of the puzzle, application bootstrap policies directly support both the smart-endpoints / dumb-pipes vision and the implementation of microservices.

With smart pipes, the danger of increased complexity is high. Smart pipes often lead to a monolithic architecture. Lewis and Fowler, in a sidebar to their write-up, state that they have seen “many botched implementations of service orientation” including the tendency to hide complexity away in enterprise service buses (ESBs).

Why is that bad? Smart pipes create an unintended tight coupling between endpoints and the pipes themselves. That is, an application becomes dependent on expectations in the communications protocols for proper function, and the general systems behavior is now defined in the pipes. A system leveraging a smart ESB ends up more often than not functionally dependent on that ESB (carrying around an ESB is quite the dependency!). As soon as pipes start to become too smart, they force monolithic creep. What’s worse is that endpoints may become co-dependent through the smart pipe with each expecting an implicit finessing of RPC and payloads to work properly.

Unfortunately, the temptation to make pipes smarter is high. In the names of abstraction, architecture standardization, and re-usability, adding logic to communication pathways between services is commonplace. What starts as a microservices architecture quickly bloats to a monolithic architecture. However, a system does need a common, orthogonal offering to keep redundant functionality low.

Does it make sense to embed authentication logic into every endpoint or to script monitoring hooks into a web service or to write code for any other non-business function in a microservice? It does, if it’s the only way to keep “endpoints smart and pipes dumb.” Fortunately, that is not the only option.

Previous generations of developers introduced techniques like aspect-oriented programming to deal with the issue of separating cross-cutting concerns from application logic for better code modularity. Interestingly, similar techniques can be leveraged in cloud-computing and PaaS-based microservices. Jon Norton, a software engineer here at Apprenda, explains an Apprenda feature called “application bootstrap policies” that allows IT operators to instrument libraries and modify any guest application.

Interested in mixing APM into an app deployment? Write a bootstrap policy. Want to modify the IL or Java bytecode of any guest app to introduce some fancy byte-level instrumentation? Write a bootstrap policy.

Bootstrap policies are a modular vehicle for mixing cross-cutting concerns into endpoints on a PaaS. The power in this is huge and should not be underestimated. Endpoints can be smart while pipes remain dumb. Most importantly, bootstrap policies support Apprenda’s commitment that all developers avoid writing unnecessary code.


Atos Apprenda Support

View Comments
  1. TechYogJoshMarch 3, 2015

    It would be good if articles like this give a “pro and cons” approach than taking a one-sided view. This does not help the end-users and clearly represent bias of the author (understandably given the author owns a PaaS company). The argument could be that the company does not see anything beneficial in those technologies that are against their vision and product. Now this can be true, but appears stretched. I am sure there are benefits in other application development methods, otherwise they would not have been this popular. In the next post it will be very helpful if you can do a pro and con analysis of what Apprenda offers vis-a-vis how do you see the market doing it “wrong”.

  2. Sinclair SchullerMarch 4, 2015

    There isn’t a bias. Monolithic apps run well on Apprenda, and we have customers who run them. Having a microservices architecture isn’t a requirement, but for many projects, a preferred end state. It seems the case, however, that most enterprises would be better served in greenfield application builds by the manageability and composability offered by a microservices architecture. Do you disagree?

    The intention of this post wasn’t to extoll the virtues of microservices versus other approaches, but instead to discuss how a PaaS might help further the microservices vision. Generally speaking, I do believe that ESBs are bulky and overkill for most architecture deployments. Microservices aren’t a panacea, and may, for example, be too much decoupling and modularity for small teams and small projects. Additonally, dealing with cross-service communication, marshalling and unmarshalling of data, etc, adds complexity. I’m not sure, though why you believe this post is the proper forum for a “vis-a-vis” comparison, especially when that’s been covered so many times via better sources (for example, Fowler’s own post covers some cons in the section”Are Microservices the Future?” in the link I provided at the beginning of the text). I encourage you to explore those links since this post doesn’t really focus on trying to prove the integrity of microservices.

Comments are closed.