Christian Posta

Recent Posts

Low-risk Monolith to Microservice Evolution Part I

As part of a two-day microservices workshop I’m putting together, I’ve been thinking a lot about how to explain monolith-application decomposition and what a transition to microservices might look like. This is a small subset of that material, but I want to share it with you to get feedback (in the workshop we go into more detail about whether you should even break up your monolith). I base this on my own tried and true real-life experience as well as my work with the many Red Hat customers I’ve met over North America for the last few years. Part I explores the architecture while the second part (to be released shortly) will cover some technology that can greatly help in this area. Follow along (@christianposta) on Twitter or http://developers.redhat.com for the latest updates and discussion.

Continue reading “Low-risk Monolith to Microservice Evolution Part I”

Share

Microservices Patterns With Envoy Proxy, Part III: Distributed Tracing

This blog is part of a series looking deeper at Envoy Proxy and  Istio.io and how it enables a more elegant way to connect and manage microservices. Follow me @christianposta to stay up with these blog post releases.

  • What is Envoy Proxy, how does it work?
  • How to implement some of the basic patterns with Envoy Proxy?
  • How Istio Mesh fits into this picture
  • How Istio Mesh works, and how it enables higher-order functionality across clusters with Envoy
  • How Istio Mesh auth works

Here’s the idea for the next couple of parts (will update the links as they’re published):

Continue reading “Microservices Patterns With Envoy Proxy, Part III: Distributed Tracing”

Share

Microservices Patterns With Envoy Proxy, Part II: Timeouts and Retries

This blog is part of a series looking deeper at Envoy Proxy and Istio.io and how it enables a more elegant way to connect and manage microservices. Follow me @christianposta to stay up with these blog post releases.

  • What is Envoy Proxy, how does it work?
  • How to implement some of the basic patterns with Envoy Proxy?
  • How Istio Mesh fits into this picture
  • How Istio Mesh works, and how it enables higher-order functionality across clusters with Envoy
  • How Istio Mesh auth works

Here’s the idea for the next couple of parts (will update the links as they’re published):

  • Circuit breakers (Part I)
  • Retries/Timeouts (Part II)
  • Distributed Tracing (Part III)
  • Metrics collection with Prometheus (Part IV)
  • Service Discovery (Part V)
  • The next parts will cover more of the client-side functionality (Request Shadowing, TLS, etc), just not sure which parts will be which yet 🙂 .

Continue reading “Microservices Patterns With Envoy Proxy, Part II: Timeouts and Retries”

Share

Microservices Patterns With Envoy Sidecar Proxy, Part I: Circuit Breaking

This blog is part of a series looking deeper at Envoy Proxy and Istio.io and how it enables a more elegant way to connect and manage microservices. Follow me @christianposta to stay up with these blog post releases. I think the flow for what I cover over the next series will be something like:

  • What is Envoy Proxy, how does it work?
  • How to implement some of the basic patterns with Envoy Proxy?
  • How Istio Mesh fits into this picture?
  • How Istio Mesh works, and how it enables higher-order functionality across clusters with Envoy?
  • How Istio Mesh auth works?

Here’s the idea for the next couple of parts (will update the links as they’re published):

  • Circuit breakers (Part I)
  • Retries/Timeouts (Part II)
  • Distributed Tracing (Part III)
  • Metrics collection with Prometheus (Part IV)
  • The next parts will cover more of the client-side functionality (Service Discovery, Request Shadowing, TLS, etc); just not sure, which parts will be which yet.  🙂

Continue reading “Microservices Patterns With Envoy Sidecar Proxy, Part I: Circuit Breaking”

Share

The Hardest Part About Microservices: Your Data

Continuing on with my series about microservices implementations (see “Why Microservices Should Be Event Driven”, “Three things to make your microservices more resilient”, “Carving the Java EE Monolith: Prefer Verticals, not Layers” for background) we’re going to explore probably the hardest problem when creating and developing microservices. Your data. Using Spring Boot/Dropwizard/Docker doesn’t mean you’re doing microservices. Taking a hard look at your domain and your data will help you get to microservices.

Continue reading The Hardest Part About Microservices: Your Data

Share

Carving the Java EE Monolith Into Microservices: Prefer Verticals Not Layers

Following my introduction blog about why microservices should be event-driven, I’d like to take another few steps and blog about it. (Hopefully I saw you at jBCNconf and Red Hat Summit in San Francisco, where I spoke about some of these topics). Follow me on twitter @christianposta for updates on this project. In this article we discuss the first parts of carving up a monolith.

The monolith I’m exploring in depth for these articles will be from the Ticket Monster tutorial which for a long time has been the canonical example of how to build an awesome application with Java EE and Red Hat technologies. We are using Ticket Monster because it’s a well-written app that straddles the “non-trivial” and “too-complex for an example” line pretty well. It is perfect for illustrative purposes and we can point to it concretely and discuss the pros and cons of certain approaches with true example code. Please take a closer look at the domain and current architecture in light of the further discussions.

TM Architecture

Looking at the current architecture above we can see things are nicely broken out already. We have the UI components, the business services, and the long-term persistence storage nicely separated and decoupled from each other yet packaged as a single deployable (a WAR file in this case). If we examine the source code, we see the code has a similar structure. If we were to deploy this, any changes to any of the components would dictate a build, test, and release of the entire deployable. One of the prerequisites to doing microservices is autonomy of components so they can be developed, tested, deployed in isolation without disrupting the rest of the system. So what if we just carve out the different layers here and deploy those independently? Then we can achieve some of that autonomy?

Continue reading “Carving the Java EE Monolith Into Microservices: Prefer Verticals Not Layers”

Share