Going cloud-native: How to develop better cloud apps

Many cloud applications are slow, clunky, bloated or otherwise fail to meet user expectations – yet answers on how to address this are out there already, if teams are given the resources to follow through from first principles.

Owen Rogers, cloud research director at Uptime Intelligence, says cloud apps should be architected to be scalable for performance and efficiency. Unfortunately, many enterprises lift and shift applications to cloud.

“Most applications will need to be re-architected to scale, which has a cost and time implication,” Rogers explains.

Jon Lucas, co-founder and director of Hyve Managed Hosting, adds that proper planning and thorough testing are crucial. “Sit down and work out the specification and your requirements, then build it in a development environment,” Lucas says.

Problems often arise when development mostly happens in the team’s heads, and later on further issues emerge when users have actually been using the tools. It is better to delay a live deployment if necessary, until the testing phase is complete with all changes fully managed, rather than just following your nose.

Ensure apps adhere to stakeholder requirements at the start as well as later on, when they want or need something else, and get it all signed off, Lucas says.

Hyve co-founder and director Jake Madders has seen the consequences of not doing this – including customers whose online applications need patching up with increasing amounts of hardware, processes and memory to support designs. An example might be difficult-to-index code in a database.

“We try and help them get through it, but actually there’s a fundamental code problem that should have been solved, saving them so much money in their hosting,” says Madders.

Divide and conquer 

Minimise the movement of data, and split off processing to be done at user browser level rather than on the server. Auto-scale web apps too, expanding processing power for auto-scaling on multiple servers only when needed. Kit deployment specifics, and content serving, caching, locations or multiple points of presence requirements when building code can all cause incompatibilities.

“Mostly it seems that some customers simply haven’t thought about just how big it’s going to get, or how many concurrent users there are going to be. The customers who do well have clearly planned for it, beyond what will work well for one or two years,” Madders says.

That’s when experienced developers can show their quality. Novices might be great coders, but typically are not thinking about things that affect the whole stack or concurrent connections, Madders says.

Grant Caley, chief technologist UK and Ireland at data storage company NetApp, says developers may not be able to optimally build and develop applications that maximise the way the software uses the underlying resources.

“They don’t have much option around that, because they’re given a tool to use – the development platform – that can cause issues around performance,” Caley says.

CIOs need to understand that developers aren’t necessarily capable of building fast apps, especially without awareness of the full stack. More time and resources are needed – particularly for testing, he agrees.

“It’s not that people are sloppy,” Caley adds. “We’re all trying to develop apps as quickly as possible because of time to market, the business moment to capture.”

Application development tools, libraries, compute, storage, networking and data management layers all sit across the development process. He suggests trying to accelerate the CI/CD process and free up more testing time, on as large a dataset as possible – especially with the rise in artificial intelligence (AI).

And if you can use the underlying infrastructure layer to instantly checkpoint those datasets and can roll them back instantly, you can have more datasets, more tests running in parallel, speeding up development.

With the rise of low-or-no code platforms, less skilled teams can be building applications, that can cause problems too potentially, Caley adds.

Stick to your principles

But Hans de Visser, chief product officer at low-code app development platform supplier Mendix, says this can often be dealt with by closer adherence to cloud-native principles.

“Apply principles of stateful objects, stateless connections to make sure that this works in a hyperscale manner,” says de Visser. “You can break your application up, into multiple micro-services or independent components, independently releasable and scalable.”

Heavy-duty, always-on components can be scaled out independently; others, like a master data management service, may have a steadier load, he says.

Some customers mix more traditional administrative applications with dedicated resources with for example running an algorithm on an Amazon Web Services (AWS) Lambda serverless service. “That can help you scale for those functions that need to cater for peak load. Once calculations have been done, size it down again,” he adds.

A third element is AI-powered best-practice. “In our platform, we have a series of bots assisted by machine learning models, detecting if the developer is basically adhering to principles that would ensure performance in applications,” de Visser says. “If they do things to cause performance degradation, we give warnings when certain patterns are applied and recommendations for change.”

AI/ML kits (Mendix has just launched one) can help developers build better applications  as well as give them guardrails and drive productivity. Other tools can help too, monitoring application performance and health – and in future, composability in applications will help drive even more flexibility.

“The trick with low-code is to abstract it and automate it to the maximum extent so that less technical people with no clue about architecture and how to build it are still able to build pretty sophisticated applications,” de Visser says.

Markus Nispel, CTO for Europe, Middle East and Africa (EMEA) at Extreme Networks, sums up the requirement as a focus on developing for “infinite” distribution of users, devices and applications – or at least, that’s the way Extreme is looking at things today.

“The location of a cloud application relative to those who want to use those applications needs to be kept in mind,” he agrees.

Nispel underlines the need for application performance optimisation across networks, managed via a cloud-based paradigm which cuts across all of IT: cloud applications are just pieces in the puzzle. Beyond that, it’s about that focus on building in quality, automation and security from day one.

“Problem is that applications aren’t always designed, developed and deployed using those paradigms, often there are legacy applications just being lifted and shifted to cloud and not fully modernised,” he says.

Source

Shopping Cart
Shopping cart0
There are no products in the cart!
Continue shopping
0
Scroll to Top