The Challenge

The CEO got up in front of the entire company and said, “Product XYZ is the future of this company; and we are going to ship V1 by the end of the year”. As the designs began to sure up, it became clear an authentication microservice was needed. The challenge was made.

“IcedPenguin, you shall lead the team that builds the Security Token Service (STS).”

Project Kick-Off

I chatted with the architecture team, the implementation team, and the product owner of the overall application and established the STS charter. We had three months to deliver a beta service (needed to start service integrations) and an additional month before we had to be hardened. This will be fun.

The Purpose of the STS

The primary responsibility of the STS was to handle authentication with our cloud product. This handled all web-traffic to the console. We replaced the existing weak cookie implementation with a JWT implementation and rev’d the core application to be able to understand the structure of the JWT, to perform authorization based only on the contents of the JWT instead of having to reach back to a centralized point (the power of digital signatures). Additionally, we designed and built a revocation mechanism so that the web-servers could be notified when a token had been revoked (as opposed to simply expiring).

The second main responsibility, and the primary need for Product XYZ, was to facilitate federated authentication for our end-points to a third party cloud service. The end-point would reach out to the STS to kick off the authentication processed. The STS would perform the handshake with the 3rd-party, and return to the end-point, the 3rd-party access token generated specifically for them.

Infrastructure

The core service was built upon Spring Boot utilizing stateless REST APIs. The ability to scale horizontally was defined on day one. We would need it to scale, ensure high availability, and as seamless upgrade mechanism (bring up new nodes, get them stable, take down old nodes).

Result

After four months of effort (plus testing), we accomplished our goal. We extracted the authentication code from our monolith and shipped it as a microservice. Additionally, we added the 3rd-party federated authentication functionality that was needed for Product ZYZ.

Microservice Discussion: I Thought Microservices Were Suppose to be Light Weight, Why Did it Take Several Months to Build?

Great question! The STS was the first microservice to be built by the company, so we were in uncharted waters. Along the way, we hand a lot of “overhead” tasks that had to be tackled and overcome:

• Containerize the Sprint boot instance and dependencies for development
• Build pipeline to auto-create the container
  • Run the unit tests
  • Publish artifacts to artifact repository
  • Integrate automatic running of tests with our pull-request review tool
• Built a pipeline to deploy the node swarm to qa, staging, and production
• Update automated test framework to run against containers
• Management of configuration settings for development, QA, and production
• Run reviews with corporate security department to approve the approach and architecture of the STS swarm.
• Preliminary monitoring tools put in place

In addition to the product integrations: * Complete audit trail in place for user authentication actions * Updating clients to interact with the STS

Continue reading

Overview

Microservice architecture is all the rage these days. With a plethora of blog posts, books, lectures, and conferences on the topic; exploding over the past few years. With that said, I'm going to jump on the bandwagon with a post of my own. Drawing from my experience as the product owner for the first microservice built at my current employer and information that I heard while attending Code Freeze 2018: Microservice Architectures.

Microservice architecture is often seen as the conceptual antithesis of the monolith architecture.

In a monolith, all of the code to support an application is shipped as a single package. One god executable that is capable of performing all aspects of the application. To archive scale with a monolithic application, one simply deploys multiple copies to production. Via configuration, some copies can handle more of one responsibly that another, but every single node is fully capable of performing any function in the system.

In contrast, a microservice application is composed of dozens or hundreds of "small" services. Each performing a single specialized task/ owning own area of responsibility. To archive scale, each microservice could consist of several redundant nodes. There might be three login microservices running and only a single tax calculator service. With the number of nodes controlled by the current level of demand.

The thing that makes a microservice, "micro", is not strictly the size of the application. But rather the number of responsibilities assigned to it. A microservice should be responsible for one thing, and do that one thing well.

Benefits

Any software developer can enumerate all of the benefits of building small testable software packages. Almost all of those arguments apply directly as reasons to build a microservice.

Simple A Microservice should be responsible for a single function. Therefore, it should be straight forward to reason about the different responsibilities that function entails, and about the different methods of failure that could be encountered. You do not have to reason about the entire software ecosystem, you only have to worry about your immediate dependencies, your datastore, and the code that runs the specific service. Any other service that is more than one hop away can be ignored.

Testable The microservice architecture demands a high degree of automated test coverage.

Isolation A microservice is self-contained. It depends on its datastore, and an API version for other microservices. When you need to deploy an update to one service, none of the rest of the services needs to be restarted, or in most cases, even notified. Simply stand up the new instances, and then cut over traffic from the old cluster to the new cluster. There is no need to coordinate releasing updates from one service with all the rest of the services in the network.

Scale Up Only What is Needed As demand increases, simply launch more nodes to maintain a seamless experience for your users or the other services. As demand wanes, the number of nodes can be decreased to save on costs. If demand is only high for one portion of your overall application, only that one part needs to grow. The order processing nodes can grow in number to support a flash sale, while the tax calculation service cluster can remain small to save on costs.

Drawbacks

As with any architecture or design pattern, there are drawbacks. The microservice architecture is no exception.

Networks of Services Often a deployed application is supported by dozens or even hundreds of microservices. Debugging the source of a problem can be challenging.

Failure Management Services need to be built with more attention to failure. As a monolith, if the application is running, one can be almost certain required dependent services are running an available. In the world of a microservice, any one dependency could be offline, making you unable to complete the requested task at hand. The possible failure of each call outside your boundary should be taken into consideration and accounted for.

Monitoring Each service needs to be monitored. To ensure the application is performing as expected and is healthy. To auto grow or shrink the cluster in response to demand. In the case of an application with 50 microservices, there needs to be 50 monitoring solutions, 50 dashboards, and 50 alerting services to get the attention of devops should something go wrong.

Continue reading