This blog asking awkward questions for folks jumping on the microservices bandwagon was enlightening from the perspective that many of the same questions are applicable to operations as they begin to tackle operationalizing all the things in an application lifecycle.
For example: “What is your deployable unit?”
Great question, isn’t it? What is your deployable unit of automation? Is it per service? Per device? Per cluster of devices? Per container?
Wait, but there’s more from this great list of awkward questions:
- Is it acceptable for another team to take your code and spin up another instance of your microservice?
- Can team A use team B’s microservice or are they only used within rather than between teams?
- Do you have consumer contacts for your microservices or is it the consumer’s responsibility to keep up with the changes to your API?
- Is each microservice a snowflake or are there common conventions?
- How are these conventions enforced?
- How are these conventions documented?
- What’s involved in supporting these conventions?
- Are there common libraries that help with supporting these conventions?
All these questions are applicable to devops, in particular, as you go about building out automated scripts, systems and orchestrating processes that operationalize the data center and make it a lean, green deployment machine.
You are going to have some kind of code, whether it’s a script or a recipe or a template of some kind, and questions regarding the usage of that code is important. Can others use it? Change it? Claim it as their own? Are they useful in a general, “here’s a basic load balancing provisioning and configuration script” or are they specific, as in “this is a piece of code that provisions and configures the networking required to ensure all 18 tiers of this very specific application can communicate”?
And as you’re developing those scripts (that code) are you documenting it? Are there <gasp> comments? Do you use a standard convention for code formatting (cause let me tell you, where you place your brackets is a matter of great technical religious significance)?
Most of those jumping into automation head first aren’t thinking of the long term ramifications of the choices they are making right now. Proof of concepts turn into pilots that turn into systems upon which all of IT relies. Rarely are you given the opportunity to go back and put any kind of standard conventions or practices into place. That’s what builds technical debt in software and, no matter what you think you’re building with those scripts, you’re building software.
Adopting the technical and methodological practices of agile development is a good thing, but let’s not ignore that along the way from waterfall to agile developers have learned a lot of lessons the hard way. That means we should, as practitioners of software-related activities within operations (and that means any one of the four operations groups in IT), pay attention to those lessons and try to avoid the pitfalls that developers have already encountered and, one hopes, overcome.
To do that, don’t just ask the awkward questions; answer them.
