X

Break New Ground

Podcast #383: Cloud Native or Low Code: What, When, Why?

Bob Rhubart
Community Manager, Oracle Groundbreakers Team
This is a syndicated post, view the original post here

badge imageThe plan for this episode of the Oracle Groundbreakers Podcast was to bring together a panel of experienced developers to compare and contrast cloud native development and low code development. Any such comparison has to start with definitions of the 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, multi cloud, microservices, agile methodology, containers, CI/ CD and DevOps.”

“That's all the buzzwords thrown into one sentence,” observes Oracle ACE Director Martin Giffy D’Souza.

Maybe that’s inevitable in discussing any tech trend. And buzz doesn’t necessarily imply a lack of validity or value.

“Talking about cloud native is talking about buzzwords,” agrees Niels de Bruijn, an Oracle ACE Director and Business Unit Manager at MT AG. “But it's also more about getting the service very small so you don't have any monolithic approach, so you have very small services that can scale easily and interact with each other. It's a whole different approach. But things can also become quite complex in 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,” agrees Joel Kallman. “It's an approach to building and running applications that exploit the advantages of the cloud computing delivery model. Well, on low code platforms, you can use agile methods for your design, for your implementation, and for your delivery. In the case of APEX on the Oracle Cloud, would you run this in a container? Personally, I would not. But, again, this goes back to the question, do I have to run something in a container, or must it be microservice defined to be cloud native? I don't think that is mandatory. I mean, who defines what cloud native is, for example. 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.”

Martin D’Souza also believes the two approaches can coexist. “You can have microservices do one unique feature that, for instance, APEX or any low code platform can't do. Who knows? 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. 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.”

But 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 Niels de Bruijn. “If you look at big companies that have very complex processes, you wouldn't start off 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 that data between various subsystems. I think this is a whole different use case than one where you would use load code. You can use APEX wherever you want. I've seen cases where in a very complex environment, low code and APEX was being used as a front end on top of that, and then we actually exchange data using web services. So that's possible. But it's a whole different topology. If you talk to architects, they will give you all those buzzwords, and they live for those buzzwords, and those projects are really big. We’re talking about multi millions of projects going on in that area. So it's not something you would do for a business department, saying, ‘hey, I've got this spreadsheet here, and I would like to have that solved in a web application.’ If you look at the numbers, the number of cloud native projects going on, those aren’t big numbers. If you look at low code numbers, those are really huge, worldwide. There are thousands of projects going on for low code projects. That's a difference there.”

Those differences are critical in determining which approach to apply. Cloud native applications, according to Oracle ACE Director and Groundbreaker Ambassador Roel Hartman, Director at APEX Consulting, “are usually smaller, very dedicated applications. The low code applications we build are usually pretty big, because if you're building a very focused, small low code application, it doesn't make sense. It makes more sense if you're building a bigger application, because the benefit is bigger.”

Understanding which approach is a matter of determining the answers to the critical questions. “Is low code application development suitable for every business problem?” asks Joel Kallman. “And 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.

On the Mic

Joel KallmanJoel Kallman
Senior Director, Software Development, Oracle America, Inc.
Dublin, Ohio

Oracle ACE Director Niels De BruijnNiels De Bruijn
Business Unit Manager APEX, MT AG
Cologne, Germany

Oracle ACE Director Martin Giffy D'SouzaMartin Giffy D’Souza
Director of Innovation, Insum Solutions
Calgary, Alberta, Canada

Oracle ACE Director Roel HartmanRoel Hartman
Director/Senior APEX Developer, APEX Consulting
Apeldoorn, Netherlands

 

Additional Resources

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.