Cloud Natives

A new startup programming company is the first cloud-native programmer in the financial services space.

Most of you either know or have heard of Oleg Tiskevich, who is a familiar figure in the planning tech landscape.  He’s best known as the founder of FinanceLogix—the financial planning program which was one of many Envestnet acquisitions in recent years.  The acquisition led Tiskevich to start a new software firm that offers something new to the planning space—and relatively new to the entire software field: cloud-native software development.

The announcement led me to do a few internet searches on what, exactly, was the big deal about cloud-native vs. cloud-based software, and how Tiskevich could make good on his suggestion that his firm could revolutionize the way financial planning software applications are developed—and most interestingly, how they talk to each other.  So before I talk about his firm, let me tell you what I learned.

Cloud-based software is nothing more than a term for any software that you access in the cloud—meaning you don’t have to store it on a server in a room in the back of your office, or maintain that server—and most importantly, you can access the cloud-based software from anywhere. 

That was a pretty neat idea, but it has its limitations.  Typically, the software resides on a server somewhere, which means that if the power supply to the server farm were to go down, or if the server were to malfunction, your applications would malfunction and you might even lose data.

More importantly, the cloud-based software is running your software requests through the entire program; that is, you log on and your CRM has to access your data, process your requests and update whatever you type in, occupying the attention of the full program while a few thousand other people are also occupying the full attention of the program.  Computers are fast, and they can handle one request at a time without you noticing anything amiss.  Mostly, this affects scalability, which is why some programs have to be housed on a number of servers which are all constantly running the same software at the same time.

How is cloud-native different?  First of all, it comes in pieces, called “containers.”  That is, instead of a single software program, you have a lot of coordinated applications or processes that can operate more or less independently.  You need data pulled from your database?  You access only one piece of the overall software solution that will do this specific task for you without tying up all the other aspects of the program.  This makes any software application far more scalable.

Second: These containers are actively scheduled and managed to optimize resource utilization.  I suspect that this is where the skill of the software developers comes in; it may not be hard to create a container that performs a set of specific tasks—in fact, you might be able to just take the coding that does the specific tasks from the particular program you’re upgrading to cloud-native.  But you want each container to know when it needs to call on another container or two in order to complete the task you’re asking for—and only those one or two other containers, and coordinate the flow of information between them as needed.

Third, these containers are built out of what software technicians call “microservices.”  After reading up on the topic, I’m thinking of these microservices as the atoms that make up the molecule that is the container.  You might think of them as apps.  The container has a lot of apps, which further subdivides the work that has to be done.  The advantage here is that if you want to upgrade the software, instead of reconfiguring the entire system (Version 2.0, announced with great fanfare two years after the software’s launch!) you can improve the microservices to do a better job of whatever they do, thereby improving the software without a total (expensive, time-consuming) rewrite.  You can add containers or their component microservices without disrupting the system; you just plug them in and presto!  A new feature has been added. 

Cloud-native applications, I am told, are constantly being improved and upgraded without the customer ever having to do an update or worrying about whether it’s compatible with other programs.

There’s a fourth difference with cloud-native software: it can be hosted in a distributed network of servers, which means it can be housed on the entire Amazon, Google or Microsoft system.  Cloud-native articles talk about load-balancing and how the traffic is accommodated by the architecture of the cloud itself; that is, the entire ecosystem of servers.  I’m not exactly sure what that means, but it seems to indicate that there is unlimited scalability if the software is truly cloud-native.

Inefficient architecture

Tiskevich says that most server-based (and therefore cloud-based) programs—which includes pretty much all the programs you’re accustomed to using in your professional software suite—are configured in three tiers.  There’s the data and programs, and on top of that is the business logic, and on top of that is the presentation layer, which is the interface.  “With that configuration,” he explains, “if I need to make a change, I have to go into my business logic, which means I also have to go into my database and change the way the business logic calls up the data in the database, and even if I need to add a field, it messes up the other stuff that I have, because everything is interconnected.”

This is why, he says, when you ask for a very simple piece of functionality from your vendor, the customer service rep will go back to the team and find out that this relatively small-seeming change will take two years and cost millions of dollars to implement.  So the software company collects a lot of these requests, and does them all at once in a big new software version.  “They wipe out the old system,” says Tiskevich, “start building the new system including all these new requests, and because it is built on the same architecture, when they roll it out, it will then take another two years and millions of dollars to incorporate any new request you might have.”

Worse, he says, you might say: I actually really liked the way the old system did this and the new system doesn’t do it that way any more.  Can you guys put that back?  “Every software developer is in a vicious cycle where they are constantly getting requests, but their software cannot be changed easily, even if it is a brand new system, because it is built on the same architecture and the same structure, with the same limitations of inflexibility.”

With cloud-native software, he says, instead of two years and several million dollars, a new feature can be added in a month or two for $50,000.  Imagine that you will soon be living in that world.

“Larger firms are looking at this and realizing that it means saving millions of dollars in operational cost savings,” says Tiskevich, “plus the ability to compete on a much higher level, to be able to adapt to clients’ requirements at an extremely faster pace than before.”

Distributed programming

The first cloud-native programs are being developed by programmers who are using the same programming languages as cloud-based software, working as consultants for Google, Microsoft and AWS (Amazon).  “The problem,” says Tiskevich, “is that they don’t understand our industry at all.  So the path they might take on the implementation side may not be ideal.”

Tiskevich’s new firm, called INVENT.us (https://www.invent.us/) is one of a very small handful of industry-specific cloud-native developers, and so far the only one in the planning space. 

The company is organized just like cloud-native software itself; during his years with FinanceLogix, Tiskevich identified top programmers from all over the world, who were as interested in the cloud-native revolution as he was.  There is no specific home office location for the firm; indeed, the company’s 37 programmers, all available on a moment’s notice, are located across 13 time zones around the world, including France, Croatia, Norway, Russia and Poland.  Tiskevich himself is located in Bellevue, Washington, and has “local” INVENT.us programmers in Hawai’i, Florida and Vancouver. 

“We really wanted the best people for the job,” Tiskevich explains.  “But it’s really hard to find the best people, and get them trained, if you are constrained by geographical limitations.  So we connected with folks I’ve worked with in the past, or who were recommended by people we trust.”

The company has entered into a strategic partnership with Envestnet, but Tiskevich is looking at a lot of different types of projects that will solve some of the most intractable problems in the profession: broker-dealers that want to scale their in-house technology but also want to connect with the independent software that its reps are currently using; advisory offices that want to connect disparate software programs that seem unwilling to talk to each other; and those disparate software programs that spend an estimated 40% of their programming time and dollars working on API (application program interface) connections with other programs.

The company is already working on a universal translator that will allow all software companies to connect with a set of microservices that will function as their API for certain types of data.

“Right now, if I have an API, now I have to connect to six different APIs for six different vendors, and talk with each of those vendors, and they have six different conversations with me,” says Tiskevich.  He notes that something as simple as a first name field might be referenced, in one program, as ‘first,” while another might use the more formal “first name,” and still another might abbreviate it: “fn”.  The expected retirement date might be listed under as many as a dozen different names.  By the time you get to more complex fields like the account data, the potential differences between translating the same information into differently configured or named fields might reach into the millions.

To resolve all that, Tiskevich plans to collect the different names for the different fields, and create applets—microservices—for each of them or each group, listing how each program refers to the same information.  Combine these applets and you have the API universal translator, allowing companies to put their programming time back into designing a better feature-set.

The potential for cloud-native software, when you break it down into actual functionality, is pretty exciting.  We’ll see programs that are constantly upgrading themselves cheaply.  Software providers will have the ability to incorporate your suggestions into your existing software without a two-year total rewrite.  Software will share information quickly and seamlessly, so your best-of-breed software stack feels like a single integrated program. 

“When you go behind the scenes at today’s software companies, there are so many pain points,” says Tiskevich.  “If people realize the potential for cloud-native programming, it will create more competition, more opportunity, and at the end of the day, the people who will benefit will be advisors and their clients, who,” he says, “will get their prayers answered much faster.”