Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
By Bob Rhubart | July 2020
In this episode of the Oracle Groundbreakers Podcast, we bring together a panel of experienced developers to compare and contrast cloud native and low-code development. Any such comparison has to start with the definitions of these terms. The definition of low code is straightforward. As Joel Kallman, who leads the development team behind Oracle APEX, explained in our previous podcast, “low code refers to application development which does not require an excessive amount of code.”
Simple enough. But what about cloud native? Here’s how InfoWorld defines it: "Cloud native computing takes advantage of many modern techniques including platform as a service, multicloud, microservices, agile methodology, containers, CI/CD, and DevOps.”
“That's all the buzzwords thrown into one sentence,” observes Martin Giffy D’Souza, Oracle ACE director and director of innovation at Insum Solutions.
Maybe that’s inevitable in discussing any tech trend. Yet, buzz doesn’t necessarily imply a lack of validity or value.
“Talking about cloud native is talking about buzzwords,” agrees Niels de Bruijn, Oracle ACE director and business unit manager at MT AG. “But it's also about getting the service very small so you don't have any monolithic approach. You have very small services that can scale easily and interact with each other. It's a whole different approach. But things can become quite complex with that approach, and low code is a part of it. You can do low code on top of a cloud native architecture, if you want to. That's possible.”
Cloud native can be accommodated by numerous low-code platforms according to Kallman. “It's an approach to building and running applications that exploits the advantages of the cloud computing delivery model,” he says. “If it is a question of how an application is built and delivered, then absolutely, you can use low-code platforms to deploy cloud native applications.”
D’Souza believes that the two approaches can coexist. Take the example of resizing an image. You can create a microservice for that, use a low-code platform to integrate with that microservice, and have a combination of both. “You can have microservices do one unique feature that a low-code platform can't do,” he explains. “We may not have called that ‘cloud native’ in the past, and people have been doing it for a while. But they can be complementary.”
“Is low-code application development suitable for every business problem? Likewise, is cloud native suitable for every business problem? Is it a function of the people doing the development? Is it a function of the scope or complexity of the business problem? How would you break that down?”
Each approach offers particular advantages when applied in the proper context. “You have to look at the use cases where we should use cloud native,” advises de Bruijn. “If you look at big companies that have very complex processes, you wouldn't start building a monolithic application with everything in it. You would split it up into several modules and eventually run those as web services and orchestrate them, especially when they should synchronize data between various subsystems. I think this is a whole different use case than one where you would use low code.”
Those differences are critical in determining which approach to apply. According to Roel Hartman, Oracle ACE director and director at APEX Consulting, cloud native apps are usually smaller, very dedicated applications. “The low-code applications we build are usually pretty big. It doesn’t make sense to build a small, very focused low-code application,” he says. “Low code makes more sense if you're building a bigger application because the benefit is greater.”
Understanding which approach is a matter of determining the answers to critical questions. Says Kallman, “Is low-code application development suitable for every business problem? Likewise, is cloud native suitable for every business problem? Is it a function of the people doing the development? Is it a function of the scope or complexity of the business problem? How would you break that down?”
Listen to the complete program for a deeper dive into how the panelists determine those answers.
Illustration: Wes Rowell