I recently spoke at the DeveloperWeek 2016 conference in San Francisco, California about JavaScript Debugging Patterns. This conference was an amazing opportunity to see and hear from people in the industry about what they’ve worked on, what they’re working on, and what they see as the future of our field.
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.
Microservices
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?
Presenter: …
(crickets)
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.
JavaScript/Node.js
Any conference in Silicon Valley would be incomplete without at least a dozen JavaScript presentations. I may be personally biased because mine was one of them, but JavaScript is really solidifying its place as the de facto way for end users to interact with a web application in a dynamic fashion. Even titans of the industry who have heavily relied on server-side rendering are beginning to embrace the benefits of the Single Page Application model.
JavaScript is really starting to come into its own with the embrace of Node.js. Talking with other developers at the conference, it seemed like all of them are using Node.js in some form or fashion. The community built around Node.js is one of the fastest growing communities in the open source ecosystem. This is a testament to both the foundation that has been built with Node.js as well as the intrinsic nature of JavaScript to move fast and fix problems.
What I saw a lot of at the conference was a desire to use Node.js as a platform for Microservices. On the surface, it sounds like a no brainer. JavaScript is loosely typed as well as designed to be small and easy to iterate. Microservices need to change with the business requirements and deployed to production in a meaningful and iterative manner. I saw many talks walking through this route in one form or another.
I’m of the opinion that JavaScript is not the right language and Node.js is not the API platform that many of our clients should use for Microservices.
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.
At an even more micro level, Node.js may not be the right choice for many of our clients based on the tooling. JavaScript as a language has been around since the 1990s, yet the tooling for it is much farther behind than other languages that are as popular and as old. We are slowly starting to catch up to our server-side peers with tools like Webstorm and Chrome’s Dev Tools, but there is only so much that can be done. The very nature of prototypal inheritance makes it extremely difficult to prove the correctness of any tool. JavaScript developers are also very good at finding workarounds and shortcuts to the point where they can get away with minimal tooling. For many enterprise architects, the lack of real industry standard tooling would be a deal breaker.
DevOps
A topic related to both Microservices as well as JavaScript/Node.js is DevOps. Empowering developers to take ownership of the life cycle of their code is a great way to improve correctness and quality. It is also a great mechanism to build automation into the pipeline where it makes sense. These themes of DevOps were frequently mentioned in most of the talks I attended.
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.
Concluding Thoughts
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.
We will also see more interest in developing Microservices using languages enterprises are already using like .NET and Java. JavaScript truly shines when it’s on a client’s browser. I do not expect to see enterprises rapidly embracing Node.js for Microservice API development.
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.
| Reference: | DeveloperWeek 2016 Retrospective from our WCG partner Keyhole Software at the Keyhole Software blog. |
