ArticleCloud Native ComputingContributory Expert VoicesDevelopers

Solving the Complexity Puzzle of 2020

0

Author: Oren Eini

Scaling your application’s ability beyond your budget requires efficiency in both cost and complexity.

When I tell my clients, “What do you want?” they say to me, “I want it to work just like Google.” Before my heart begins to pound like a hammer, I say, “Great! Google’s R&D budget is $21 billion, how much of that do I get?”

When they inevitably reply, “not much,” we start the conversation again with understood expectations. However, these expectations don’t necessarily have to veer that far from a Google like app. The challenge is to manage cost and complexity to scale out beyond your budget.

CRUD at Warp Speed

The opportunities of today come in with the speed and scope of data.

Create, read, update, delete, or CRUD, is still the bread and butter of most applications. Exponentially more data is coming in through devices, automatic generation, and AI adding potential, but it demands attention.

Asking your application to show a table now requires the data set to run on a desktop, mobile device, even micro-size IoT endpoints.

This is today’s complexity challenge: To process and distribute data at a speed and scale considered science fiction just a few years ago.

Here are 5 ways developers can solve the puzzle:

Division of Labor. There will be higher demand for creating boundaries within applications. More coders will start saying, “I develop the UI, the back end is someone else’s job. The other people on my team comprise the front end, while we collaborate together with the people working the API.”

This is likely to put more pressure on the architecture of the system, creating the proper interfaces to collaborate between the different teams and making sure that they can integrate properly.

Farm it out. As developers dedicate more time to the core features of their project, there will be a rush to hand off workload to external places. A developer will say, “I need to have persistence for my application. I don’t want to work on it.”

In the same way that today you’ll reach for a Grid component, in the next decade we are going to see much bigger tendency to create a solution by joining together different pieces, with the major value being not in each piece, but the sum of all parts.

A DBaaS service that handles your database configuration, back end ops, updates, and security so you can just worry about your data is one example of a solution. Add some machine learning as a service, which requires little effort from the consumer and a dash of good design, and you have a winning recipe.

Integration. If you try to do it all yourself, it will be too much to handle. Experts of specific technologies will find new equals in experts of integration.

Say you want to show a map in your application. This is a non-trivial problem with three worlds of complexity behind the scenes. But you can just make it happen using an external “black box” component.

Using a Google Maps API, you can install a Maps feature on your application. This gives applications the ability to say, “We can do what Google can do,” because they are utilizing some of their components.

Maps are just the beginning. You can already do face recognition using Azure’s API without actually needing to know much about how it works. There are already doorbells that use these features to decide whatever the door should be opened or not.

By bringing together such services in innovative ways, you can create systems that appear to be magical. In other words, we are reaching sufficiently advanced technology.

Order mine with everything. If you want to search your data, your database needs to have that ability or you will need to add another component. The ideal way to manage complexity is to use components that are as feature rich as possible, minimizing the need for too many moving parts and needless integrations.

Don’t DIY. If you don’t have something in the box, you have to provide the box. That can cost time, money, and lots of frustration. If your components are missing components, you run the risk of having to develop them yourself.

Conclusion

For the coming decade, the drive will be to localize the workload of in-house developers and strategically optimize the use of outside components to deliver an application that meets today’s standards while staying within budget.

The winners of this decade will be those components that have the most robust feature menu built in to manage complexity and enable developers to focus more attention to what distinguishes their application from the rest.