Soundbyte 397: Watch The World Burn

2 June 2019

It is Sunday night and my glass is half empty. To get into the right mood for this Soundbyte, I’d suggest to play the video underneath. WHAAT? Is that too loud for you? 😉

Three weeks ago I had the opportunity to deliver a keynote speech on Cloud computing to a room full of C-level executives and IT managers of international enterprises, at a seminar in Rome. The core component of my message to them was that Cloud computing is no longer optional and that we need more software, we need it faster, and we need to be able to deal with a rate of change never seen before. These pose a bunch of challenges that come with it. Not in the least the simple question: How?

Presently there seem to be two opposite ends of dealing with this: At one end of the spectrum there are these bat shit crazy ideas of throwing IT-illiterates at the problem. From OutSystems, Mendix and Betty Blocks, to even Amazon’s secret project. ‘Citizen Developers’ is what we call them now. The idea behind these so-called ‘low code’ or even ‘no-code’ environments is to invent something that will solve all our IT problems by just generating away. Sounds a bit like the monkey behind the computer, that will eventually come up with a Shakespeare play if you wait long enough. On the opposite end of the spectrum we work hard to push as much complexity down the stack. Sweeping it all under the rug if you will. But this is not just making things simpler, as you get lost in between the side cars and service meshes. Because is 2019 and if you’re not running your own on-premise FaaS on Kubernetes you must be living under a rock. Furthermore, having a carpet that is already above knee-height because of all the crap underneath isn’t a pretty sight. So somehow, I don’t think that throwing more Kubernetes at this is going to help either. Don’t get me wrong, I see the benefits of container orchestration tools, and containers in general, but as a means of isolation. Not as a new computing paradigm by itself. My take on this is that we are still on the wrong level of abstraction. Let alone that most developers will probably never really understand how all of this stuff works. 

We, as Luminis, try to address these challenges too, with the recent new release of our Information Grid. And by describing some of the extremes above, I’d position us somewhere in the middle. So that’s a little less bat shit, and a prettier carpet. We strongly believe that having a data strategy in place makes you more resilient to change. Change which is inevitable. As we see more and more proof that Cloud is shaking up entire business models, resiliency is no longer something that should be engineered into just software systems, but it has to be engineered into your software strategy and therefore into your business strategy as well. Event sourcing, accommodating schema changes, and powerful, expressive domain specific languages to gain insights into your data, or to generate user interfaces, are key ingredients to tackling these challenges head on. Our interpretation of the concept of ‘low code’ is: ‘less handcrafted code’. Less handcrafted code is not a denial of our proficiency as software engineers, but it is a testament to that we can outsmart common problems with sophisticated software engineering.

At the core of this approach is data management. Mind you, modeling data is not a trivial task. It never has been. But having a platform that keeps the modeling fluent over time beats the crap out of a 35 BNF relational data model that just keeps end-state, which over time requires significant migration efforts for even the simplest modification. The ability to keep things fluent helps in dealing with change. This is something that we’ve learned from pursuing modularity in software systems for many years. The missing piece of the puzzle so far is that we have to find a fitting solution to keep the underlying infrastructural model fluent as well. And this is where the modern Cloud comes in…

It is about time that we shake off the constraints of thinking in terms of computers. With Cloud we no longer have to throw (virtual) computers at problems. Instead we can throw a mix of endless compute, storage, and higher level managed services at these problems. This is largely due to the advancements made in Serverless computing. Not just FaaS, but all the higher level infrastructural and even middleware services which can now become engineered -as-a-Service into our software solutions.

But there is no free lunch. So while we have a new powerful array of solutions at our disposal, we have to pay a high price for using them. And I’m not just talking about pay-as-you-go pricing here. Basically what I am trying to say is…Conway’s Law. Again? Yes, again! Adopting Cloud based solutions in a truly cloud native way requires organizational changes. This is not news. DevOps is not new. Yet somehow I still come across many companies that think DevOps is grabbing an Ops person and putting them in a team of devs, and all is well. In reality it doesn’t work this way. The comparison to adopting Agile is easily made. How long did it take us to adopt agile in organizations? Sure, it didn’t take us devs long to see the benefits and so we started implementing it. At first we thought that product owners weren’t that important, and we could leave them out. Or worse, we asked the architect to play their role. Then we thought it was a good idea to have scrum masters as hierarchical roles in our organizations. And so on… It has only been in very recent years that entire organizations got convinced of the ideas of incremental software development and we have reached a certain maturity level. And that took us what? Ten years? So how would that be any different in adopting something as radical as true DevOps and Cloud native computing? The only difference this time…you probably don’t last another ten years if your competitors, or someone with a different take on your existing business model, will beat you to adopting it.

After my keynote in Rome, someone came up to me and asked: ‘how are we going to manage re-educating all of our IT staff in this new day and age?”. And my answer was: “natural selection”. It is already happening as we are on a quest to reducing the number of people required to deliver technical solutions. So in other words, we’re trying to automate the mediocre IT engineer out-of-a-job. Does this sound silly? Well, I think this is exactly what is happening right now. Look around you…how many sysops, admin, and DBA jobs have disappeared already? Programmers are next. Of course not all of them are going to disappear, only the ones failing to make the transition from programming as their only skill to the many skills that are required to become a true DevOps/Cloud engineer. Do you know that in the typical Cloud project only 20-30% of your time is actually spent on writing code? Whereas in a typical mainstream on-premise development project you usually spend 70-80% of your time behind your IDE. We are in a profession of life-long learning, yet somehow it has been way too comfortable over the past 10-15 years. Wake up and make the jump.

If you still think that Cloud is nothing new, I’d say it is time for another job drink. But then…some people just want to watch the world burn (bonus points if you recognize this as a garbled Dark Knight quote). Here’s to half empty glasses!

Leave a Reply

Your email address will not be published. Required fields are marked *