This blog post is a retrospective of everything I saw geared specifically toward what we at Keyhole see as our place in the future of consulting.
It seemed the theme of every other talk at the conference was specifically on Microservices or touched on some aspect related to them. Everyone from startups to blue chips like IBM are embracing Microservices. There were talks about how to pivot organizations to fit into the Microservices paradigm, how to develop them if you’re a startup, and the different cloud offerings related to Microservices.
In general, I saw companies try to profit off of Microservices in two different ways: help walk companies through the transition phase from a Monolith to Microservices, or provide Platform-as-a-Service or Infrastructure-as-a-Service to let them do the transition themselves. Both approaches have their pros and cons, and context makes a big difference in which approach makes the most sense.
For Keyhole, we feel that we provide the most value to our customers by guiding them through the process rather than selling them on any particular product. We have Microservice projects in both .NET and Java, and have experienced both Azure via Service Fabric and AWS. Where we fit into the picture ultimately comes down to what makes the most sense for the client, and helping them understand their options as well as implications.
Microservices are honestly a question of when rather than if. It seems like everyone in the industry is leaning that direction because of the architectural style’s proven track record in helping business adapt to changes in requirements that merely being Agile and developing a Monolith never allowed them.
It also seems like everyone in the industry is going to be suffering from the same thing relatively soon: sticker shock.
Microservices are hard. They are really hard. They are an architectural style that requires discipline in both business process and implementation. Microservices, like I tell our clients, will not solve all your problems, just make a lot of your really painful problems more manageable.
To that end, I believe in the next six months to three years, we will see an influx of Microservice projects that are beginning to show signs of trouble. Clients understand that the pattern is solid, but their implementation of the pattern needs some guidance. I think this is very clearly demonstrated by the conversation I saw at almost every Microservice talk at a the conference:
Audience Member: What is the rule for how big or small a microservice should be?
A lot of literature on Microservices deals with happy path and macro-level ideas that it feels daunting when it comes time to implement them and many micro-level decisions need to be made. We see Keyhole’s role in this process as a technical lead to help clients in need figure out what they’re doing right with Microservices as well as what they can tweak to make the process go better.
We have a fairly unique position in that we work in different clients in different fields in different technical stacks doing Microservices. I personally talk with our developers on a weekly basis to see where the common struggles are with Microservices. One thing I hope we can do more of as a company is publish blog posts and public-facing advice on how to overcome the hurdles that we see many people go through in the Microservices implementation. We as a company are sold on the idea where it makes sense, and want to help people not only see the light but guide them through to the other side of the tunnel.
I know this is a controversial opinion, but it is based on my experience at the conference as well as validated by talking with architects in the industry.
The enterprises we work with tend to be adverse to change for good reasons. They are responsible for developing the products that make their business money. If there are major issues with those products, the business ceases to make money, which causes the business to fail. Architects take their job very seriously, so they appreciate small incremental changes which can be shown to add more value than the previous iterations.
Shifting minds from Monoliths to Microservices at a technical level is easy to do, but architects understand the cost in terms of developer training for this switch to be very high. Taking a .NET or Java developer and telling them to develop as well as deploy in a Microservice fashion is tough enough. When you then switch them over to a loosely typed language with prototypal inheritance and tooling that is well below industry standards, you run the risk of thrashing. Our brains have a high cost when it comes to context switching, and this paradigm shift is costly enough without throwing in a completely foreign language. I saw this theme echoed in the comments and thoughts of people I talked to.
An area of advice that Keyhole can provide is in the different tools and practices around DevOps. Companies can either pay a third party to teach them or pay for a tool that will do a lot of this for them. We tend to prefer empowering customers to solidify their DevOps processes so they can be the ones to maintain it long term.
A big reason why I see teaching DevOps as a more preferable option to paying for a tool is for the sake of sustainability and maturity. There are so many different platforms that offer DevOps functionalities that picking the right one is difficult. Any choice of a company like that does run the risk that the third party which offers the tool stops supporting it after some time. Sure, they do have a faster ramp-up time than training people, but the long term benefits are also less.
Getting developers up-to-speed is in our views a holistic way to increase developer productivity as well as happiness. We as developers tend to be a few degrees of separation removed from end users. We write code, pass it off to QA, which is approved by the PO, which goes through a change control committee, and if approved will go into production a few months later. The Microservices architectural model allows us to slim down that time to an extent. DevOps allows the developer to take ownership of their code as it moves through all the pipelines and security checks. This puts developers closer to the real people that actually use their code. Developers by nature love to create, and there are few things more fulfilling than knowing that someone’s live is improved from the code that you wrote.
The field of Microservices needs more thought leaders at a micro level than we have now. Every enterprise architect I’ve talked to sees the value of Microservices, which means we’ve reached critical mass on blog posts trying to convince architects to move away from Monoliths for workflow-oriented, BASE applications. What Keyhole will see instead is a need for guidance on a micro level when things need tweaking for Microservice projects.
DevOps will continue to be a big topic of conversation in the years to come. There is a great level of maturity we need to get to as a field in what tools work best for which problems. Keyhole’s role in this transition will be to guide and instruct full time developers of an enterprise on the best ways to use these tools, and empower them to take ownership of their code as it moves through its lifecycle.