Guest: Nati Shalom (LinkedIn, Twitter)
Company: Cloudify (Twitter)
Show: 2022 Prediction Series

Nati Shalom, CTO and Founder of Cloudify, shares his predictions for 2022. He believes that 2022 will see multiple domain specific languages, with HashiCorp Configuration Language (HCL) being the most dominant one. Check out his predictions in the video above.

[expander_maker]

Swapnil Bhartiya: Hi, this is your host, Swapnil Bhartiya and welcome to our 2022 Prediction series. And today we have with us once again, Nati Shalom, CTO and founder of Cloudify. Nati, it’s great to have you back on the show.

Nati Shalom: Thank you very much. Happy to be here, and happy 2022.

Swapnil Bhartiya: Before I ask you to pick up your crystal ball and share your predictions, please quickly remind our viewers, what is Cloudify all about? What do you folks do?

Nati Shalom: Cloudify is… We see it as the next generation Open Source DevOps automation framework with a mission to allow DevOps teams to double and triple the number of environments that they can manage, and support by taking away a lot of the complexity of the glue code that becomes the part of their daily job and I’ll talk a little bit more about it later today.

Swapnil Bhartiya: Excellent. Now it’s time for you to pick up your crystal ball and share with us your predictions for 2022.

Nati Shalom: Sure. Before I’ll do that, I’ll just start with… Pick up a context in terms of how I see the evolution of the DevOps automation and why it came up with those predictions. I’ll start with a quote from Spotify on what they call the speed paradox, which I actually like very much, which basically says, “The faster you grow, the more fragmented and complex your software ecosystem becomes, and then everything slows down again.” And this is really talking about the reality in which we’re really not short of DevOps automation tools. What we’re seeing right now is that, if we really look in retrospect of how we started the automation, the first challenge that we had was really moving from moderated application to distributed microservices, to meet the scale. We also had focused very much on moving from semi-manual to manual processes, to automated processes.

So a lot of the tools that we have right now, whether it’s Terraform Ansible, to some degree, even Kubernetes was really built around that time. How do we actually create this architecture paradigm that will allow organizations to really move into the cloud and run natively in the cloud itself? And that’s where a lot of these tools were built, and this is still very much the set of tools that we’re using today. What is changing is… And that’s really what I call different times called for different measures is that those tools still remain the main foundation, and they’re doing a pretty good job, but the reality has changed. What has changed, first of all, we have a lot of new tools. We have DevSecOps, MLOps, FinOps, GitOps, and soon EdgeOps. So that becomes part of our, I would say DevOps five plan.

Obviously, we’re moving to a lot of distributed type of architecture. So the entire… I would say architecture and workload that we’re dealing with right now is very different from the workload that we had to deal with earlier today. So we are moving to market services, servers, multi cluster, and multi site and again, edge and wherever. And the other things that I think is also shaping this type of world is really the number of tools that are coming up almost on a daily basis that are focused on Kubernetes, focused on other things. So we have an explosion of those tools like CI/CD tools every second. And that’s the reality that we’re seeing right now. And that leads to a lot of complexity, which we’re basically creating a supply and demand type of problem where DevOps team that used to be… If you like the agility solution for organization, becoming now the [inaudible 00:03:33], because they have to deal with a lot of this integration and the tools that they have right now doesn’t address a lot of the integration between the tools.

That becomes a huge challenge. And that leads me to the prediction that in general, what we’re seeing is a lot of focus on dealing with the next generation problems really around productivity and how do we build the pipeline towards this world? And I’ll start with that prediction. So I’ll start with the first prediction. First of all, it’s reducing the infrastructure. It’s called development complexity for developers. Not that I’m emphasizing developers, because soon I’m going to talk also non-developers. By developers, really what we are seeing is two, if you like, can hope of thoughts on how we look at the automations. One of them is led by telephone to a large degree, which is Infrastructure as Code, type of thinking. And in that context, they basically have a specific domain, specific language to deal with how automation needs to be done, which is called the HCL language that is very commonly used today.

On the other side, we do see things like [Pulumi 00:04:43] and other things that is looking at that as a software, basically trying to create automation that will be built like any other software. Between the two worlds, I think that it’s becoming very clear that automation is not yet another language. It is domain specific. It is very distributed. There is a higher chance for partial failures. And in my view, the HCL Terraform approach will probably prevail more so towards that and even quoted Pulumi founder that I think, recognizing that this is going to be the main trend. What I do believe will happen is that, we’ll see more ecosystem build around Terraform as we are already starting to see, to augment some of the things that it’s missing in terms of its language capabilities, the barrier to entry to write Infrastructure as Code and things on that and along that line.

So what we’re going to see is still HCL becoming the main domain specific language, but we’re going to see other languages like CloudFormation, Azure on the case of the cloud providers, but also other more domain specific language built around it. And that’s going to lead to reality in which we’re going to have multiple domain specific language and HCL is going to be the center in a lot of that, and probably the most dominant one. I don’t see a shift towards this software based approach, towards the likes of Pulumi in my view. That’s the first prediction. So we’re going to see more of that domain specific language rather than going towards Java, or other native languages. The second prediction is how do we reduce the barrier to entry for non-developers? And that’s in my view, a very big thing because we’ve seen it actually in marketing automation happening where in marketing automation, we can see a lot of tools that has been built [Monday 00:06:37], I think is a good example for that.

And another type of automation system that really made the writing of automation task, at least the repeatable one, very easy. And part of the things that enable that or helps to get that is obviously the maturity of the market, but also the fact that we have a lot of pre-templatizing environment. So we have databases of service and we have already a template within, by Amazon, or Azure, or obviously HashiCorp to do that.

We don’t have to reinvent the wheel on that regard. There are many of that type of a pre-templatizing environment available today. That really allows us to start and think of how we do the Low Code type of approach, where we can drag and drop things and put them together, so that non-developers those that are not familiar with code or deeply in code could actually work on that. Having said that, I do believe that the No Code type of approach and the Yes Code type of approach needs to coexist, because I do see a scenario in which we’re starting with something that is Low Code or No Code, and then build down into Yes Code for things that will require more complexity.

And the fact that… Tools that are creating some barrier between the two olds creating really, make it very hard to choose any of those approaches because that are clearly different trade-offs between each one of them. So to summarize, number two is really the ability to reduce the barrier to entry to non-developers by allowing a No Code to live alongside the Yes code type of models. The third point is the speed in which we can release… basically new releases by democratizing the development environment from the production. And, what do I mean by that? If we look at how organization are really building their pipeline and their environments, what we’re seeing in that regard is really a case in which… Because, let’s say the production environment and development environment is very different. In development environment, want things to run very fast.

We want them to be isolated. We want to test things and then kill it after we finish it. With production, we actually want everything to be redundant, entirely available and keep everything alive. What we’re seeing is that in many cases, building an optimized environment for each of those cases is becoming very complex and very hard for the teams. And therefore, they’re trying to use one environment that will cater for both use cases, even though they’re very different. That complexity really slows down the development because they’re basically using the production system or at least production life system as the main set of tools that they’re in framework for running that type of environments. Kubernetes really allows us to abstract a lot of that differences and really allows us to choose the right framework for the job. So we can use, for example, Minikube for development, and obviously EKS for production and even EKS itself provide different flavors for actually doing that.

What we’ll see is tools that are really making the ability to create this different permutation and different flavors of the same environment that will be tuned for each of those use cases and will make the job of creating those optimized environment per use case, much easier. And therefore, we’re going to see much more of that democratization that will be happening in the development environment, in the testing environment, so that we can really optimize for that and not compromise on some production SLA that will slow us down quite a bit, as we move along. So that’s the third prediction. The fourth prediction is really streamlined. What I call the continuous changes between IT and DevOps. What do I mean by that? So on IT, organization are really using a completely different set of tools like ServiceNow, which is part of the ITSM, the IT Service Management family, which really were built to deal with tickets, support tickets.

You want to order a machine, you want to order the laptop, you open a ticket, and that’s how things goes. Where on the DevOps world, we’re using Gitops and we are using Git actions, and we are using obviously everything centered around Git, and that becomes a center of universe, and that’s how DevOps teams are really working today. Those tools, those two worlds have become very separated to a large degree and that gap, even though we are trying to close that, still very much separated organization, and now asking the DevOps team to expose their Infrastructure as Code into their ITSM so that we can have the tools closer together. The reality though is that the DevOps team doesn’t know how those IT tools works. They see it as something that slows them down. So what they expect is really to see as much data integration that will become more in an other box experience.

And that’s something that we actually, specifically in Cloudify working closely with ServiceNow to really enable the ITSM guys to get access to a lot of the environments that the DevOps teams are created through infrastructure is called automatically exposed into ServiceNow, without having to have a mediator in the process, and without forcing the DevOps teams to actually know how ServiceNow works.

And then, I’ll move to the fifth prediction. And one before I think the last, and that’s really the cost efficiency. So I’ve seen… I think, I’ve talked about it quite a bit on how much cost is going to play an important factor and how we structure and how we run our operation. Obviously, a lot of the cost systems are built to… If you’d like more to the CIO of the organization, and less to the developers. But if you want to really optimize, like in the rest of the shift left type of trends, if we want developers to actually take ownership on how the system optimize for cost earlier in the process, rather than later, we have to make a shift on how those tools that are presenting the cost efficiency becomes much more usable for developers themselves and are becoming part of the development stack, if you’d like.

Again, this is very analogous, very consistent with the rest of the trends, the rest of the shift left trends like we’ve seen with DevSecOps in the security side, and now it becoming FinOps on the financials or cost and onsite side. The other thing is the choice of infrastructure becomes more flexible. And this is to large degree due to the maturity of Kubernetes. So Kubernetes really allows us to abstract a lot of the complexity of the infrastructure itself. And one of the trend that we are seeing, and this is related to the cost is repatriation where some organization are taking better control of the stack that they’re using right now and trying to decapulate from, as they scale from the minute services that the cloud provider really provides, because it’s going to be much more efficient for their use cases.

And Kubernetes really allows those organizations to actually take an entire stack and run it. And they need to get data center that is completely optimized for the workload. And in that case, really enable them to scale and be much more efficient on how this infrastructure cost is taking place in their stack, in their tool chain, and in their food chain of their stack itself. Again, the maturity of Kubernetes, the maturity of the tools around Kubernetes are probably going to increase that trend and we’re going to see more organization that are starting to take higher control over the services and not just run everything on the cloud itself, which is opposite trend and how we started the journey with the cloud. Where do we fit with all that, basically what we believe is that we need to have this higher level of orchestration that will manage a lot of those automation tools and will provide organization and the teams themselves, something pre-canned.

So rather than them doing the glue code, we can actually provide them something that pre-integrate a lot of those automation tools that I mentioned earlier. And by that, simplify the way we can structure, not just how we optimize or automate security groups, but how do we create an entire cluster. How do we create an entire database. How do we create an entire end to end environments with all the networking, Kubernetes, data based storage as a unit of work and not worry about all the tiny gritty type of resources around it. And that next level of automations will really help to simplify how we deal with that next challenge that we’re been discussing in this prediction.

Swapnil Bhartiya: What is going to be the focus of the company? I’m pretty sure that a lot of [inaudible 00:15:34] reflect on the prediction that you shared here, but tell us what are you focusing to focus in 2022?

Nati Shalom: So the focus in 2022 is really, we call it Terraform first approach, or really simplifying the Infrastructure as Code challenge that I mentioned earlier. That’s going to be the first challenge that we’re going to tackle. That will also include the No Code type of capabilities that I mentioned. So really exposing infrastructure is called also to non-developers. That’s going to be the second part of our focus. And really making a lot of that processes that we’ve been discussing here right now, streamlined and simplified.

Swapnil Bhartiya: Thank you so much for taking time out today. And of course, talk about the company, your focus and these predictions. Thanks for sharing this prediction. And as usual, I would love to have you back on the show at the end of this year. So first of all, to check how many of your predictions turn out to be true? And then second is to get new set of predictions for next year, but thanks for your time today.

Nati Shalom: Thank you very much. Happy to be here and happy 2022.

[/expander_maker]