Have a safe microservice journey!

mountains road

An architecture needs to bend, not break, as new innovations, best practices, and needs emerge. In this post, I’ll explore the broader landscape we are traveling to support that agility.

In my last post, I talked about the relentless focus on experiences, rather than spending a lot of calories on the things that aren’t directly contributing to a strategic digital strategy. Being able to iterate on experiences quickly helps create a competitive advantage. I couldn’t agree more with my colleague (and co-engineer on much of this journey) Matt McLarty when he said that “change itself is an expected feature of the product”. An architecture needs to bend, not break, as new innovations, best practices, and needs emerge. In this last post of the series, I’ll explore the broader landscape we are traveling to support that agility.

Deconstructing the monolith

I spend a lot of time thinking about the adoption of any new technology. When I think about the journey to microservices, I can’t help but come back to Martin Fowler’s strangler analogy and how that lays the tracks for an architecture where legacy coexists with new. Although there are many benefits to be gained by moving from a monolith to microservices in a manageable way, there are still some challenges. Issues such as scaling talent, security concerns in new integration patterns, and managing system safety properties can potentially derail the journey. To that end, the following is a look at reassessing the infrastructure (or the lack thereof) for service execution, and the security model surrounding a heterogeneous application network.

Mind the gap

When I clipped that quote from Matt above, I happened across this tweet as well:

matt mclarty tweet

In those few characters, I decided that a service mesh discussion should be part of this blog series as well.

The capabilities of a service mesh in part overlap the capabilities offered by an API gateway, but in a different topology and tuned for east-west microservices traffic. While service mesh and API gateways are good for inter/intra-service resiliency and protocol support, service discovery, and observability, they both miss the full lifecycle of microservice development: Design >> Publish >> Secure >> Deploy >> Analyze. As we bring the mesh into the application network to offer those capabilities, a single interface will offer a way to manage APIs and to deploy service mesh properties.  

Since application networks are a mix of heterogeneous services that span the spectrum from microservices to large monoliths and SaaS apps, no single gateway can provide all required mesh capabilities across that granularity spectrum. For that reason, multiple technologies will be leveraged, at both the application level and at the networking levels underneath, to meet those needs. It is MuleSoft’s vision to unify the experience of orchestrating and managing this combination of technologies on Anypoint Platform.

Security

The microservices landscape features an ever-increasing number of integration and API management patterns (such as backends for frontends and API Gateway, sidecar, etc.). This creates an ever-expanding surface area to be governed and secured. Without a thoughtful and consistent security approach across that heterogeneous landscape, an organization would find it difficult to adapt its traditionally restrictive security posture of policies that start with the word “no.”  MuleSoft puts security front in center of design to overcome that friction and offers it in the same Anypoint Platform where these experiences are being created.

I find it’s helpful to look at security models from other industries as a frame of reference. For example, airport security is applied in layers.  

Step 1:

Validate identity and flight info to be authorized to enter terminal.

Step 2:

Scan and inspect bags and body for illegal content.

Step 3:

Pass through heavily monitored terminal to reach appropriate gate.

Step 4:

Validate flight info and priority status before boarding plane.

This provides a clear analogy for the heterogeneous digital landscape:

Step 1:

Validate credentials before allowing network access.

Step 2:

Scan and inspect payload for illegal content.

Step 3:

Monitor and meter access through layers of API gateways.

Step 4:

Authenticate, authorize, and audit API access.

Layers of security applied in this way will ensure a secure, zero-trust application network.  

The application network begins with a strong, independently-audited foundation that serves as the base of our entire integration and API lifecycle. The relentless resourcefulness of bad actors in the industry has proven that security by obscurity does not work. The only reasonable and scalable approach to security is to adopt robust, well-known standards. MuleSoft puts the platform through the rigorous checks and audits to achieve ISO 27001, SOC 1, SOC 2, PCI DSS, GDPR, HIPAA, SSO, RBAC, FedRamp in process, and soon, authorized to operate (ATO).

Built upon that base, the next layer of security protects the APIs and integrations themselves.  Edge gateways protect against vulnerabilities, such as from a denial of service attack or as protected with our web access firewall capabilities. API-level security offers policies that can be declared and applied automatically for AuthN/Z, validation, filtering, whitelisting, tiered SLAs, to name a few. Automatic feedback loops between the Edge and API gateways automatically detects API attacks across APIs and escalates them to the perimeter so that the edge updates its own blocking policies to eliminate vulnerabilities before they ever make it through the perimeter.

mulesoft layers of security

Where these layers of protection in Anypoint Platform offers unmatched capabilities at and through the API interface, MuleSoft offers capabilities that also protect the final boundary at the data itself.

As a microservice does not, in fact, have to be the “source” of the data (caveated by its adherence to principles that maintain its independent deployability such as through queuing and sourcing patterns), messages can move across the application network in ways that may have yet been expected and could potentially put that data at risk. Data leakage, payload logging, or even common development mistakes done in the spirit of agility and removing friction can have disastrous effects. Malicious or not, if sensitive data isn’t actually “useful,” then that last mile would continue to be protected. In that way, MuleSoft added capabilities to Anypoint Security services to protect sensitive data completely with vaultless, format-preserving tokenization services.

It’s the journey, not the destination… and it’s just beginning

My goal with this blog series was to offer a pragmatic approach to achieving business outcomes through a microservices architecture that aligns strategy, culture, and technology. I hope I’ve hit that goal, but I also realize there is plenty of ground to cover for future blog posts.

For now, a final thought: do the things that make you different, not the things that make you the same; and in doing so, fail fast, and keep moving forward.



We'd love to hear your opinion on this post