Cloud Is The New WebSphere
By: Jerry You
Tags: Containers, Development, Cloud Computing, AWS, Service Mesh

Have you heard a thing called “EJB”?

If you were not coding Java at early 20th century, you most likely never heard this name. Not your fault. It is a “enterprise Java” thing, and abandoned by the community for good reasons long time ago. It was huge around 2002 when the idea was introduced to us Java developers. I even bought a book “EJB in Action”. Although the book and the idea that it was talking about have been lost, but the history may still be able to teach us something interesting today.

So what is EJB?

In early days Java and its ecosystems are largely sponsored by big companies like IBM, SUN, etc through “committees”, filled with smart people from those server (particularly WebSphere, WebLogic) vendors and consulting firms. EJB is the “enterprise” version of Java bean, with the idea to separate the concerns and go full “O-O”.

A “Java bean” is just regular Java object that has properties and the “getter” and “setter” methods. EJB is more that that — for example it also knows how to save itself to database and loads from there by id. There is where the “Enterprise” came from since most of the corporate applications are dealing with CRUD operations. Basically, EJB is Java object that has soul and life cycle, living within the container (application servers like WebSphere). And the web app developer can just use it through some configuration and plumbing on servers.

I remember the view of future development from the author of the EJB book:

1, EJB is developed by dedicated team or vendor, to handle the database and middle-ware stuff, there could be a market where you can purchase them.

2, Server admin will deploy EJB or the middle-ware to servers. Configure them, and make them accessible through the runtime.

3, Web app developers will not need to write or worry the back end any more , because they can just create the reference, and it will be hooked up to whatever the underlying mechanism at runtime.

The idea is to have app developer to focus on the implementation of the business logic, and leave the heavy lifting middle tier to the EJB developer, or rather IBM consultants. It sounded interesting but faded quickly after one year or two. The problem is that this architecture was tied deeply to app server vendor’s interests, and the complexity from the layers of abstractions was just too much for regular developer. In reality we often only had one developer, Jack, and now he has to work on both the web and EJB, even worse now Jack had to spend more time (and request) with server admin, everything just became slower.

Not only EJB didn’t deliver the promise, it backfired and triggered a movement to “go back to basic” (Plain Old Java Object). The community switched to prefer the lighter container and framework like Spring, which kept the core concepts:

1, The container, just lighter.

2, The “don’t call us we will call you” by Inversion of Control, so Jack the developer can use something “injected” at runtime.

As far as Jack is concerned, his work load didn’t get much smaller, although he may have saved some database coding with Spring and ORM (another container).

Then fast forward couple of years, Google made public Google App Engine (and Rails folks has Heroku). Jack now can just package the web app, and upload to GAE with one click. Instantly it works, he gets a host name like “mystuff.appspot.com” automatically. There is nothing to SSH, all he needs is to specify the server capacity and fill the billing info. If he wants to use queue, he can define it in the configuration and use it in his code.

GAE and alike were exciting and promising, like answers to Jack’s wish at least for the infrastructure needs. That is what app developer’s view of infrastructure should be like. It is there, all he needs is to ask. He does not care the where/how/what, it is in the cloud.

But interestingly, the cloud providers didn’t continue to build up from GAE for the “dev guy”. They somehow took a detour, with the business model mostly from the view of “infra guy”. The narrative of cloud was eventually taken over by AWS EC2. In the past years the cloud has been largely built bottom up vertically, and expanded horizontally. However for Jack, things didn’t become easier.

Let’s say Jack is now building APIs. He still and will always need to code the business logic. He also relies on couple of configuration items, data from a database, as well as another piece of data from a remote service. Jack needs to code everything, handle all types of failure scenarios, and use cache wisely. Obviously Jack has learned some good practices in past years still that is a lot even with help from frameworks and libraries. There are more though. Now Jack needs to decide and work on:

1, will the API be deployed to server-less environment like Lambda plus API gateway or container?

2, If container, what image? port? Docker file? How to test?

3, If on AWS, Fargate? EKS?

4, The configuration item. Environment variable? S3 file? Parameter store?

5, Caching. Redis? Memchached? AWS or other managed service?

6, Database. AWS managed? What flavor?

Some of them must be decided early on for example the Lambda vs Container. Others can be left later. But you get the point — Jack needs to be aware of lots of things, most often need to work with couple more engineers to make decisions and make things happen.

What can we do to help Jack? Let’s take a top down approach and understand what minimum knowledge/skills that Jack needs to fulfill his responsibility.

All Jack really needs to write that API:

1, access to request and set response in his code

2, couple configuration data, JSON format.

3, querying data at database

4 , another piece of data from a remote 3rd party service

He will not care of where the configuration data is stored, or the database connection, or the HTTP call to remote service. Jack will just use the data like “it is there”. Jack does need to decide what action to take if “data is not there”, but he will not need to write the error handling code at lower level though.

Jack only needs to focus on business logic, with minimum reference to lower level. His code will live within its own light container and Jack can test it easily.

Down the stack, we will have another engineer, Stefanie, to make the decision that Jack didn’t do. For example:

1, it will be deployed to container environment, CPU, memory stuff.

2, configuration will be stored in parameter store

3, AWS managed Postgres

4. …

To make sure the API meet business’ needs, Stefanie also need to specify more things for example:

1. anything about high availability, scalability

2, logging, monitoring etc

3, priority, budget etc.

Once decisions are made, Stefanie create a YAML file and specify all the things that the team needs, many of them have name like “connector” like one for AWS parameter store, one for database, and another one for HTTP calls. She doesn’t need to write code for all of them because they are already built by others. Basically Stefanie just declare “here is what we need and how they should be configured and assembled at runtime, please make them happen”.

At this point, whatever Jack is expecting from his code will be fulfilled by what are declared and specified by Stefanie. Neither of them has to write any code for the connectors or hookups, because they are already built.

We just need someone to make the stack and assemble those middle-wares. It is the responsibility of Steve the “Infra” guy. He also need to make some decisions, for example to choose a cloud, AWS vs GCP vs Azure or all of them if budget is allowed. With the information and requirements from Stefanie, Steve can make the decisions and start to work on putting everything together and building a stack, including both the resources and the components that Jack needs. It’d not be hard for Steve because he has already done so for the other teams.

This is really the same idea that we had years ago. Our applications live in the cloud. The cloud is our runtime. Whatever we need we ask from cloud. Someone else build them. We specify what we need and the real thing is injected at runtime.

The Cloud now sounds more like WebSphere. Maybe the EJB thing was not too bad.

I think what is different this time is that our industry is ready for this type of separation, because of the built up from past 10 years. Bottom up or Top down, somewhere these two must meet each other.