• Home
  • >
  • DevOps News
  • >
  • A Model for Managing Microservices in Cellular Self-Organized Teams – InApps 2022

A Model for Managing Microservices in Cellular Self-Organized Teams – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn A Model for Managing Microservices in Cellular Self-Organized Teams – InApps in today’s post !

Read more about A Model for Managing Microservices in Cellular Self-Organized Teams – InApps at Wikipedia



You can find content about A Model for Managing Microservices in Cellular Self-Organized Teams – InApps from the Wikipedia website

We’ve said it time and again — modern systems are complex. Now, it’s up for debate if Conway’s Law — where the technical systems’ design reflects the culture and communication of an organization — is desired or not, but there’s no doubt it is almost a constant. The risk of distributed systems is that everyone and everything is so distributed that there’s not a clear path of how things are connected and who is in charge of what code and for how long.

Paul Fremantle, co-founder of WSO2, told the audience of QCon London how he attempted to apply the simplifying models of math and physics to distributed systems. What he found was that the constantly changing complexity of distributed systems is much more akin to endlessly evolving cellular biology.

“Biology isn’t about trying to make everything super simple, but it’s about learning how to deal with complexity,” he said.

Both human bodies and modern distributed architecture are similarly complex systems.

Today we will share WSO2’s cell-based approach to microservices, where the code is reaggregated to reflect deaggregated, agile organizations.

What’s Keeping Enterprise Agility from Becoming a Reality?

“What’s happened over the last 50 years is we are disaggregating our systems — smaller and smaller, serverless and microservices,” Fremantle said.

He said the need to scale and move faster is driving this. However, he cited the 12th Annual State of Agile Report that, while 58 percent of organizations are using agile practices to support this, only four percent see their organization as a whole being agile to adapt to market conditions.

Read More:   Update The Problem with Too Many Databases

There seems to be a massive challenge to take the agility on teams and build a team of teams — like a scrum of Scrums — to take agility to the enterprise level.

Fremantle argues this difficulty to be agile on a united, cross-organizational front is because there is simply so much fragmentation. From APIs and endpoints to functional components to fragmentation at runtime and platforms to Kubernetes and microservices, we are moving farther and farther away from the hardware to orchestrate. Being cloud native inherently makes things more fragmented and complicated.

He continued to tout problems like how complex service-oriented architecture (SOA) processes — and the wrong tech stack in general — interrupt flows with excessive steps. And layered architecture makes it so you don’t have control over the things you need control over.

Fremantle argues that while we have decoupled a lot of the architecture, we’ve yet to decouple the organization. Referencing the Agile Manifesto’s focus on self-organizing teams, he said we need “composable” enterprises, too.

For him, this enterprise is made up of self-organizing teams that:

  • Manage their own work
  • Pull work
  • Don’t need command and control
  • Communicate effectively within teams
  • Are not afraid to ask questions
  • Evolve skills and capabilities constantly
  • Have a servant leader or facilitator, not project managers and leads

Fremantle argues to limit teams to fewer than 10 members. With the formula below, he says if you have 10 people on a team, that’s already 45 connections. Eleven? Fifty-five connections. 20 people leads to 90 connections. Like with software, these many interconnected pieces make things really complicated, leading to relational loss.

n(n-1)
______
2

But once your organizational structure looks like this, how do you make sure the tech reflects it? (Also Read: Microservices: Terribly Named, Ambiguously Defined)

How Conway’s Law Can Offer More Control and Visibility into Your Stack

Fremantle offers APIs as natural boundaries, as they come with:

  • Expected, required authentication
  • Authorization
  • Rate limiting and throttling
  • Analytics and observability
  • An assumption that others will use it:
    • Developer-friendly portals, like SDKs, samples, and forums
    • Developer-friendly governance, like versioning and depreciation notifications
Read More:   What is the difference between UI and UX design? A Quick Guide

A lot of people are putting sets of microservices behind API gateways that are providing more version control. But remember that you need to know who is using your APIs and what they are using them for, he said.

He analogizes that the control plane acts as a biological nervous system, while the data plane acts like the circulatory system. He also points out that nowadays there is no brownfield versus greenfield development — only both.

“We have our core systems in the brownfield and disaggregated and microservices in greenfield. Most people are putting in some kind of API platform, some way of isolating the backend systems from the services, and that gives us the potential to strangle away parts of the architecture.”

If one team of 10 devs is in charge of 200 microservices, no one could know all of them, but there could be collective knowledge. With this in mind, Fremantle argues that 90 percent of microservices in any deployment should not be visible outside the team to anyone who deploys it. Otherwise, someone else other than who built the service makes a change and everything breaks.

“We need governance and boundaries,” Fremantle said. “[It] allows you to keep your agility in your team and lets you be self-organized.”

He continued that we need to reaggregate those microservices — not all the way back to monoliths, but into something that is owned by a team.

He shared the following time-lapse video of sponge reaggregation to illustrate what he calls a natural reaggregation of microservices.

“APIs enable the boundaries, and the boundaries enable self-organizing teams.” — Paul Fremantle, WSO2

Continuing the metaphor, he said there should be stateful and stateless cells, some wrapping legacy stuff, and teams figuring out how to categorize these cells or groups of microservices.

At WSO2, as an API management system, they are looking to mimic this cellular reaggregation technologically with tools and systems. They are attempting to automatically visualize the organization of Kubernetes and microservices. (Also Read: Miniservices: A Realistic Alternative to Microservices)

Read More:   Update Big Data: Google Replaces YARN with Kubernetes to Schedule Apache Spark

A Cell Acts Like a Higher Level of Abstraction

The WSO2 Methodology for Agile says just about every new application involves integration across an exploding set of endpoints.

“Integration must learn from code to become immutable, type safe, testable, continuously built and deployed so they are more robust, resilient and above all — agile,” reads the paper.

It becomes a modernization of Conway’s Law for organizations, founded in continuous improvement:

  • For both people and process the foundation is the culture of an organization.
  • For technology the foundation is the architecture designed and implemented by the organization.

“We need a higher level abstraction — and that’s really what a cell is,” Fremantle said.

With this in mind, Fremantle offers three guidelines for microservices and tech in general to catch up to team agility:

  • Have a clear global data and control plane — offering an API management platform to accomplish this
  • Ensure teams offer clear boundaries — versioned APIs through the control planes
  • Give teams freedom to evolve within these boundaries — like the cells around these groups of microservices

“Should we change human nature or write code? It’s easier to write code. We should be building our systems around Conway’s Law.” — Paul Fremantle, WSO2

He continued that everyone is on a journey toward agility, but integration agility has yet to catch up to the speed of project agility. In order to enable this integration agility, you must reaggregate code with a cellular structure to reflect the self-organizing teams who then are in charge of measuring the health of each team’s cell.

Continuing with this theme of restructuring your code around your teams, he said it’s about recoupling decoupled components into new agile teams within the flow of DevOps, cloud infrastructure and intracell communication, making sure that every agile step inside the cell is versioned and behind a gateway at the boundary.

“Biological systems have evolved into complexity. And what I think is really interesting is enterprise systems have evolved into complexity,” Fremantle said.

Read more about this cell-based restructuring here.

WSO2 is a sponsor of InApps.




Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      [cf7sr-simple-recaptcha]

      Success. Downloading...