DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Data
  4. Microservices: Organizational Practices, Part 2

Microservices: Organizational Practices, Part 2

DevOps and microservices go together like peanut butter and jelly. Read on to learn out why!

Pavel Micka user avatar by
Pavel Micka
·
Feb. 12, 19 · Analysis
Like (3)
Save
Tweet
Share
7.11K Views

Join the DZone community and get the full member experience.

Join For Free

Welcome back! If you missed Part 1, you can check it out here.

Conway's Law

Let's first discuss Conway's Law, which is an observation published in 1967 by Melvin Conway. It states that:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

This basically means that the architecture of our system will always resemble the organizational structure of our company. The reasoning behind this is quite simply the result of the fact that when a team is assigned a task to implement a component of software, it needs to cooperate with other teams. As an example - whenever the team reaches the boundary of some other component maintained by another team, the engineers need to agree on a stable communication protocol between these components and they create APIs.

We can also use the other side of the law, the so-called Inverse Conway maneuver. When employing this technique, we restructure the company in a way that stimulates the creation of the desired communication channels.

In our case, we want to strengthen the communication between engineers working on the same business features (from database to APIs), hence we put these engineers on the same team. Within the restructured team, strong communication occurs internally, there are no longer strong APIs on the technological level (between business logic and database, for example), instead, these APIs will appear on the boundary of the team. So we end up with REST (or similar) APIs encapsulating the business subdomain. Which are, coincidentally, microservices.

We want the team to be responsible for the full release cycle, as this bolsters the shared responsibility for the component. It is no longer possible to say that "it was developed/tested/deployed incorrectly" when the whole team owns all these activities. There is now no need to find the culprit, now it's more important to find the root cause.

Taking the Next Step

Restructuring the team and improving internal communication not only leads to the development of well designed and tested microservices, but they also lead us to the logical outcome that the strongest cross-functional team conforms to the DevOps model.

Why DevOps Is Important for Microservices

Apart from the improvement of communication channels, cross-functional teams are also far more effective when it comes to the software development lifecycle. Here, it is important to remember that in the world of microservices, this cycle does not happen only once, it happens dozens of times (each time a new service is introduced). For teams with a traditional layout, where developers only do the programming work, it is common that they need to create a support ticket to:

  1. Create a Git repository.
  2. Create a pipeline in a continuous integration system.
  3. Create a project in a bug tracker.
  4. Provision machines for testing.
  5. Create a deployment pipeline.
  6. Deploy a new version to production.

With this modus operandi, the team can easily spend more time waiting for others than actually working.

Implementing DevOps

Dev-Ops Axis

DevOps teams mitigate this issue by being able to act as both development and operations teams at once. One way to augment a traditional team is (if development and operations are separate entities) by inserting one operations engineer into each development team. This dedicated engineer should support the team during the setup phase (points 1-5) and supports the team with the deployment of automation (continuous delivery) and monitoring of the system in production. While initially there is limited overlap between the work done by developers and the operations engineer, the ultimate goal should be to create some redundancy of knowledge in the team. This means that each member of the team should eventually be able to set up a new project and maintain the service in production, while the operations engineer should be able to work on features with developers.

This does not mean that everyone in the team will be top-class developers or top-class operations engineers — on the other hand, the developers will be able to spin up new projects and they will know how to maintain the production environment (and debug issues, if things go sour). In this scenario, the skilled operations engineer will be able to provide feedback on code during development, making sure that potential issues are cleaned from the code early on.

Vertical Axis

These newly created teams should be given responsibility for some subdomain (vertical cut) of the product. This may be, depending on your product, something like Customer Management, Parcels, or Delivery scheduling. Being responsible for the vertical cut puts your development team in the position of being domain experts in the subdomain and stimulates the creation of microservices.

Conclusion

In this two-part article, we have described the advantages of microservices from the point of view of the organization: fast releases, reduced mean time to recovery, resources/costs savings (using autoscaling and cheaper hardware), as well as easier growth and onboarding within the company itself. We have also shown how we can use the inverse Conway maneuver to stimulate proper communication channels within the company — those which lead to fine-grained and reliable services. While ensuring that all processes are managed by self-sufficient DevOps teams.

microservice teams

Published at DZone with permission of Pavel Micka. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Load Balancing Pattern
  • Top 5 Java REST API Frameworks
  • An Introduction to Data Mesh
  • Using JSON Web Encryption (JWE)

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: