When approaching development of Microservices, it’s often easy to think of the services themselves as the valuable pieces of your system. Each service you add gives you more functionality, and so more value. For the majority of systems we have built and reviewed during our consultancy, we have found that the system itself is of fairly marginal value. Instead, the data that it contains and the intelligence it can provide based upon that data is what is actually valuable. This seems a subtle, even academic distinction, but it is important and putting it at the forefront of your mind during design has significant repercussions on the way you build your services and the way that they interact with each other.

When building microservices, you have to naturally distribute your application around a network. It is almost always the case that you are building in a cloud environment, and often using immutable infrastructure.

The Challenge of Dynamic Service Location

In traditional monolithic applications, components communicate through in-process method calls. With microservices, these components are distributed across a network, and their locations can change dynamically due to:

• Auto-scaling events
• Service failures and recovery
• Deployments and updates
• Infrastructure changes
• Container orchestration

This dynamic nature makes hardcoding service locations impractical and brittle. Service discovery provides a solution by enabling services to dynamically find and communicate with each other.

No programmer likes to plan for their work to be taken offline and shutdown, but part of good antifragile thinking is allowing things that aren’t successful, to end. Applying that to Microservices, one of the natural parts of that architectural style is creating and destroying instances of a service. As part of the lifecycle of services, you sometimes have to create different versions of a service, and so manage the retiring of a previous version (although we try to avoid versioning where possible).

A question often posed to us during our research and project work is “how should I secure a Microservice?”

When it comes to securing microservices, two primary approaches dominate the landscape: session-based security and OAuth/token-based security. Each has its strengths and weaknesses, and understanding these differences is crucial for making the right architectural decisions.

Session-Based Security

Session-based security represents the traditional approach to web application security. In this model:

Recently (June 2015), I gave a talk at the DDD Exchange at Skills Matter in London.

This was a little last minute! The (then Simplicity Itself) CTO, Russ Miles, was originally scheduled to deliver at the conference, but he had to be out of the country visiting one of our partners and so I was drafted in to deliver.

This is a talk I’ve wanted to give for a long time, so while it was a little rough around the edges, the message is something we’ve been working with for a while.

The software development industry has an enduring fascination with finding the “silver bullet” - that one methodology, practice, or tool that will solve all our problems. From the early days of computing to today’s DevOps and microservices movements, we’ve seen wave after wave of “best practices” that promise to revolutionize how we build software.

But is this constant search helping or hindering us?

A Brief History of Silver Bullets

Looking back over the decades, we can see a clear pattern:

The promises of adopting the cloud for your software are enticing. Effectively limitless scalability, large reductions in capital expenditure, efficiency savings in staffing through automation. An exciting prospective, and one that has being brought into even greater focus by the rise and rise of Microservices.

Not all is sweetness and light, however. There is significant investment required in ensuring your organisation and software can make best use of the new environment of the cloud. That investment in technology, training, development approaches and aligning the business with the new adaptable technology world can be significant, and the potential for a misstep to cost and lead your organisation into a dead end is present and you are right to be wary.

All Hail the Command Object

This is a follow on to Simplicity in Web Architecture – Beware the Stateless Service

In that article, I gave my opinion on the Stateless Service programming model, and why I think it has been overused and touched on some of the issues it has caused.

It developed out of my unhappiness with the way I see code layed out in many Spring and Grails applications. The Service layer becomes stuffed with all the important logic, kept away from the domain and without much in the way of support to be had from the excellent Object Oriented language that Groovy is.

Simplicity in Web Architecture – Beware the Stateless Service

This article is related to my recent talk at the London Groovy/ Grails User Group which you can see at SkillsMatter

In that talk I presented a way to get back to an Object Oriented way of thinking within Grails, using the existing infrastructure to help us get away from the Stateless Service paradigm that we have so deeply embedded in our psyche.

Peter Ledbrook recently wrote a blog post about the future of Grails, which sparked some deep thoughts about where Grails is heading as a platform.

As a long-term Grails user with interests in programming in the large, functional languages, DDD, CQRS, and high-volume HTTP, I’ve been contemplating what the future holds for this framework.

The Changing Landscape

The industry has changed significantly since Grails was born. Grails emerged from the Spring/MVC consensus - essentially designed to be “Java/Spring web development done right.” It was, and continues to be, a better Spring MVC paired with a better Java (Groovy). This approach has been beneficial to the industry.