Over the last 10-15 years we've seen the industry adopting microservices in order to achieve a number of benefits often related to scaling technology and organisations.

The pattern has also been emulated for the frontend in what is known as microfrontends.

To enable this evolution, many organisations have adopted DevOps practices to provide greater collaboration and leaner processes between developers and operations, because, quite simply, it's hard to maintain a larger number of deployable components if deployment cycles are slow and collaboration is inefficient.

Part of this work has been providing developers with good self service tools and APIs so that they can carry out their deployment tasks with, ideally, ever increasing independence and efficiency.

Many organisations have found value in providing standardised configuration patterns and middleware when general infrastructure-as-code tools turn out to be too low level of abstraction for their needs.

Over time, in-house practices, tools and APIs have developed into what we refer to as internal developer platforms, and organisations opt to have dedicated platform teams to maintain and expand the platform in the hopes of improving automation and enabling better compliance and security.

Despite the good intentions, more and more we're seeing that the platform and its corresponding organisation comes with a built-in temptation to centralise and pursue (fictitious) economies of scale, and I think it's fair to say that a lot of teams are realising that they have invited the ghost of the monolith back in to the house in a different shape.

It's therefore prudent to start thinking about the next step in the evolution of the platform with a strong emphasis on its original DevOps aspirations.

We might call this step Microplatforms.

I believe they will have some of the following traits:

• Deeply specialised to the needs of individual teams
• Organisationally decoupled
• Might reuse or further abstract components and policies from upstream platforms on an opt-in basis.
• NOT separated from the development teams by a ticketing system
• Well-suited for ownership by cross-functional teams
• Small
• Quickly iterated
• Easily replaceable
• Maintained and expanded with the primary emphasis on removing friction from developers in delivering value

We would do well to remember the hard earned lesson, that when it comes to software all things are better when they're kept small. Micro, in fact.