Is the Microservices architectural Pattern similar to EJB 1.0?

While there are some similarities to the ideas behind the original EJB spec and what is being done with Microservices, there are many differences.

EJB provided a standardized way of building component-based architectures, with contracts to ensure the products of a bean can be consumed by other architectures, while abstracting away transaction, state, and thread management. The idea of building components is very similar; the biggest change is we are now calling them "services." The idea of contract-based development is also similar.

Some of the high level differences are provided below:

• The specification for EJB states: "Enterprise beans are intended to be relatively coarse-grained business objects." This is in contrast to a good Microservice implementation, where the best design is a bounded contexts with a single concern.

• In an EJB 1.x architecture, the container is the persistence provider; while in a Microservice architecture, each service manages its own data and persistence.

• With the Microservice pattern, transaction management is simplified by minimizing your the scope and never having transactions cross Microservice boundaries.

• With Microservices, thread pools are per service or instance of the service. If the thread pool is exhausted, ideally you spawn another instance of the service. In an EJB 1.x environment, the thread management is the responsibility of the container.

There are many other differences between the Microservice architecture and the EJB 1.x architecture, but these are some highlights. I have worked with implementations of both architectures, and the maintenance costs of a Microservice architecture appear to be lower so far. Especially when considering the mess EJBs have become within monolithic architectures.