Communication and Service Oriented Architectures
I was going to say ‘DevOps’ in the title, simply as click-bait. But, in the interest of precise communication, I swapped it out for a term that has a definition everyone can agree on: Communication.
Service Oriented Architecture is the slightly-older new hotness. That is to say, it’s not really one of the hot buzzwords anymore, but it is very much on the minds of many organizations.
Most of the buzzwords these days are, ostensibly, about increasing communication and removing barriers and obstacles. Lean, DevOps, Agile, etc are generally about distilling out efficient and rapid processes to deliver high-quality products quickly. That’s not always how organizations implement these things, but that’s the idea.
###DevOps And SOA
I read an article just now while planning out this post. It’s from January 2011 and reads more like an advertisement than anything else, but it does make some good points. The article is Why DevOps Depends on SOA.
It’s a pretty short article, so feel free to read it yourself, but the basic point is that DevOps is seeing increased adoption due to more cloud-y/SOA-y applications.
Unfortunately, it misses several points. While it pays lip-service to communication and culture/process, it is ultimately an advertisement for tooling.
So, I’m going to make the corollary: SOA Depends on
###SOA and Communication
On its surface, SOA has many of the same goals as the aforementioned buzzwords - modularity, loose coupling, specialization, and separation of concerns allow for rapid and efficient development where each service team is able to work at their own pace.
One of the dangers of SOA is that it almost inherently builds up silos. It creates insular teams that are inevitably only concerned with their corner of the world.
In some ways, this is the point of SOA. Teams can work at their own pace without blocking one another and everyone is happier and delivering a better product.
If each team is practicing ‘DevOps’ (sorry, I’ll try not to use the word too much) and Continuous Deployment and all that fun stuff, things can seem pretty great.
The hidden danger is in practicing SOA without practicing
DevDevcommunication between service teams.
In an SOA world, an organization can (and maybe should) start to look like a collection of individual companies all moving data back and forth across APIs. And having everything loosely-coupled like that is great, it provides so many benefits that I’m not going to enumerate here.
However, anyone who has ever worked even a little bit with 3rd party APIs can tell you one big problem with it…
Crazy, right? Services interact.
One of the benefits of working for the same company is that it is easier for service teams to share and collaborate with one other where it makes sense.
People love to say things like “I can write my service in Java and you can write yours in Ruby; SOA must stand for ‘so awesome’.” That’s true, and that is pretty cool, but…why bother?
A SOA should probably start to look like a healthy open-source ecosystem.
If teams can agree upon certain standards, it can save everyone a lot of time and effort and raise the quality of everyone’s services.
If you have a shared source code server - a GitHub Enterprise, an Atlassian Stash, something like that - developers can put up some small modules to help with common problems. Cross-cutting, domain-specific items can be solved once, and the best modules will “float to the top” and propagate through different services.
Another benefit of standardization is that you increase local expertise on your chosen language and framework. A larger pool of experts, and getting the experts to communicate with one another, allows the best design patterns and advice to propagate through the organization. It also increases chances for collaboration or even lateral movement between teams.
If there is a bug fix or improvement that one team has requested of another team’s service, they could even implement it themselves and submit a pull request. Healthy collaboration can increase happiness, as the teams will communicate instead of just insulting the other teams behind their backs.
Lastly, increased collaboration means teams can make use of certain shared infrastructure. I know ‘centralization’ is a bad word these days, but it can be really valuable. Even if the services are separate, they all serve the same organization, and they all interact in essentially a closed system.
A good example is a logging and monitoring infrastructure. These services are interacting, so being able to get information about all of the services and their interactions from a single system accessible by everyone can lead to faster identification and remediation of issues, especially since teams can more easily share their data instead of working separately/siloed in their own services without even knowing the other team is investigating.
###That’s a lot of words for a simple lesson
More communication is always better than less communication. Building trust and collaboration between teams leads to increased happiness and probably a higher quality product.
Separation of concerns != Silos.