The Cloud is finally ready for Banks

The cloud, the cloud, the wonderful cloud. The solution to all our technology problems in one simple word. I'd like to order 2 Internets, 3 Clouds, medium fries and a Coke. If life was only that simple.

Most conversation about whether banks are ready to take on the cloud have historically been centered around security. Yes, security is obviously very important. But I feel for the longest time people have been ignoring operations risk. This is not something the cloud introduced, rather an element that has been there all along. Thus people simply became accustomed to it and managed it by building ginormous IT organizations. But the cloud has come a long way.

Let us take a step back and ask what we exactly mean by the "cloud"? Well, there are many answers to this question depending on the context of the problem and the era in which it is asked. So let us start to peel the onion.

In the beginning there was...

Cloud computing. At the core, cloud computing is just "someone else's computer". Don't be fooled by the marketing hype. That's really all it is. I am not saying "and therefore it's worthless". Quite the contrary. That is why it is fantastic! Because:

It's no longer your problem
That other guy is probably better at it than you are since they do it for a living

But the primary beneficiary of offloading compute resources is really the IT department. So if you are a customer of your IT department, while you are happy for them that their lives are easier and more efficient, that's an execution implementation detail of the IT department and, to be blunt and selfish, "not really your problem". And therefore your business needs are still not addressed. IaaS (Infrastructure as a Service) is great at giving you indirect benefits, but you want more direct benefits.

The Dev-Ops revolution

Then along came Containers and PaaS (Platform as a Service). Developers (and IT departments who must provision these services) rejoiced! Services like databases and application execution environments became available at a click of a button. Its management became "someone else's problem". In conjunction with Dev-ops tools like Docker, Vagrant, Chef, and Ansible, resource you need as a developer became much more accessible.

So banks and financial services vendors started building away, like a kids left alone at Lego Land. But in reality all that had been solved was resource management. IT and developers would no longer have to replace failed hard drives, upgrade air conditioning vents, install the latest software patches, take backups. Again, I am not belittling this. That in it of itself is a paradigm shifting change. But you still had to do something with those resources. So developers started doing what developers do best: writing code. Lots and lots and lots of code.

Embarrassment of riches...

Open source is nothing new really. But it had traditionally been dominated by core foundations like Apache and Linux that have a small handful of extremely well respected, unbelievably dedicated people managing/moderating the code. Then along came GitHub and changed the entire landscape. YouTube made sharing video accessible to everyone and not just television broadcasters. Talent naturally rose to the top.. eventually. But not without suffering through years of cat videos and skateboarder epic fail clips. GitHub did the same for software accessibility.

In my opinion, the most important thing that came out of the chaos of open source, specifically for business users, was the creation of commercially supported open source software vendors: an interesting concept of making money supporting something that is free. Here are just a handful of examples:

Redhat (Linux & JBoss)
Pivotal (Spring)
Datastax (Cassandra)
Mongo (MongoDB)
Elastic (ELK)

Some industries are more mission critical than others. Healthcare and Finance are the poster child of the "really, really can't fail" application. The millennial generation out there probably care more about Snapchat's latest features than HIPPA compliance or whether their 401k is backed by a Ponzi scheme. But when it comes to services that fundamentally touch the heart and soul of people's lives, nothing else comes close. Naturally these industries have tougher challenges as they not only have to meet their users' needs, but do it in a way that conforms to massive amounts of regulations and internal scrutiny. When Netflix servers go down, they lose a $9.99 subscription from an angry user. When the same happens at a bank, they get shut down. Or worse, sectors collapse, countries default. So having your dependencies backed by someone who has legitimate "skin in the game" is very important.

Companies that embraced open source early lived through the crazy chaos and headaches of what at times seemed like a poorly supervised kindergarten classrooms. However those who survived came out transformed and able to react, be agile and adapt to today's newer challenges. Some, like Netflix, surprisingly became contributors of software. It is still such a bizarre feeling for me when I'm on my couch catching up on episodes of House of Cards while simultaneously having a com.netflix... import statement in my Java code...

A core series of frameworks matured which where:

Opinionated (which I am a big fan of!)
Enriched by a vibrant open source community
Supported by commercial entities
Used by significant companies in the real world

Developers could stop rewriting the same boilerplate infrastructure code everyone else was. You could finally focus, not on resources, not on deployment, not on infrastructure, but on functionality!

And then came Big Data...

Inexpensive and globally accessible hardware and software infrastructure meant that everyone was building applications and generating data (and tons of it!). And since storage was easy and cheap, why not store it and analyze it? An entire sub industry was formed to support the injection and processing of big data: Hadoop, Elasticsearch, Spark, Hazelcast, MongoDB, Hive, etc. If you go to apache.org and search for projects categories under "big-data", you will find 38 projects. Thirty-eight! And that's for one topic at one organization only. Imagine if you went to a Toyota dealership and the SUV category had 38 different models. This was how wonderfully vibrant yet terribly chaotic the big data revolution had become.

After a while, people realized that big data and analytics was great, but there was simply too much of it. Having your EOD process tell you that based on your data between 1-2pm, you would have a critical business crunch at 2:10pm is great and all... but wouldn't that information have been more valuable at..say.. 2pm??? So then came the era of Streaming Big Data. Technologies like Kafka, Flume, Storm, Flink, Akka grew in popularity.

Oh, and this is all of course built on the premise that you have already solved the underlying pre-requisite of having access to a massively, horizontal scaling compute, storage, and orchestration infrastructure. And if you don't... well...you do have lots of money right?

The world was becoming a more and more interesting place.

What have we gotten ourselves into...

"I miss the days when we could just focus on writing the code against the functional specs" - Me.

So now delivering functionality was no longer your largest technological challenge. Even with the help of countless dev-ops tools, cloud solutions and software frameworks, you still need to solve one of the most fundamental issues of "can I handle the work load?"

Traditionally banks and large institutions used to be able to overcome this by scaling vertically. Yes, it was prohibitively expensive, but at least you had an out. But not anymore. Moore's law and Einstein couldn't keep up with the magnitude of world's appetite. You had to scale horizontally.

I am going to make a blanket statement here: "Converting your vertically scaled enterprise application into one that scales horizontally is... well.. impossible".

There I said it. Sure. Nothing in programming is by definition "impossible". And I'm sure someone is gonna stand up and say "no no we did it". Ok fine. I'm sure you're not telling the whole story, but you get a gold star anyways. But for the rest of us mere mortals, there's simply too much inertia against you (legacy code, internal politics, morale, etc). It's a fundamental different way of thinking and coding. You may not even want to use the same programming language. You may need to embrace polyglot persistence. You may need to introduce micro-service architectures. You may need to switch all your modules to a functional programming paradigm. And the scariest of all: your staff may have no idea what any of those words mean.

You may be able to spend a lot of money and extend another year of life into your solution, but don't fool yourself or be tricked by a vendor into believing whatever hybrid solution you have is anything more than a stop gap. There's absolutely nothing wrong with stop gaps and bandages. There is a time and a place for everything. But make sure you are being honest, at least with yourself.

Micro-services to the rescue!

I'm sure by now you've heard of micro-services and how it's the only way to go. But remember that it is only a philosophy and not a solution. 20 years ago people were convincing everyone that XML will solve the world. And that "self documenting data" was the end all of data transport. Bandwidth and data storage had just gotten an order of magnitude cheaper around 2000 and XML tried to leverage that. Today you will hear people laughing and saying that XML is stupid and anyone who doesn't use JSON is an idiot. Let's see what people in 2030 say about those people. I bring up these examples to illustrate the point that trends are just that. They take advantage of the eco-system at the time and provide an opinion of how to optimize the situation. Every philosophy has its pros and cons.

Having said that, if your organization is large enough, I am quite the fan of micro-service architectures. It is not the technical aspect that I value but the human one. I believe it empowers teams and minimizes cross team politics. At the end of the day, we are all human beings. And we trust our own team more than those in another team (and our own organization more than another and our own company more than another).

I am not going to go into detail about micro-services. There is plenty of material online explaining and debating all sides of the coin. I bring this up here to point out that micro-services may be an important tool in managing scalability, but is not a solution in it in of itself.

Containers to the rescue!

The other buzz words you've heard of are containers and container management. Here too there is a raging battle for supremacy between solutions like Kubernetes, DC/OS - Mesos, ECS, and Docker Swarm. Containers promise to create disposable boxes of deployable code being managed by orchestration software to handle clustering, load balance, and failover.

While I view these containers and orchestration software to be incredibly interesting and powerful, I feel their existence somehow fundamentally misses the whole point of cloud. It makes me feel like when the guy at the electronics store was trying to sell me on a 1000 disc CD-changer. Isn't what I really want an iPod? Or better yet, Spotify?

There is obviously a time and a place for containers and orchestration software, especially for real-time, memory and logic intensive applications. But I am somehow left feeling that this is just an evolutionary solution to the previous step. A solution that has lost sight of the original problem.

Game changer: Server-less Architectures

As a programer, there have been 2 constants in my life:

I write code
My computer runs the code

Open source has significantly reduced the amount of code I have to write. And with the birth of schema and annotation driven frameworks, there is quite a bit of code generated behind the scenes.

So #1 is becoming less and less true. But clearly #2 will never change right?

Everything I have talked up to now speaks to how the world continues to throw new demands and how various products make doing it easier. But in most cases we still have to do it. The exception being when we want to run someone else's service like an OS or database software. Then we have PaaS to do it for us. But surely we have to at least run the code we write right?

This is where server-less architectures are a complete game changer. For the first time, we really do only need to focus on the business logic we write. This is tantamount to each block of your own code being a mini PaaS solution

FaaS (Function as a Service) offerings like AWS Lambda, Azure Functions, and Google Cloud Functions, allow you to write a single operation in the coding language of your liking. This code is registered, then is dynamically activated in response to an event (user clicking a button, API getting called, row insert into a DB, a timer invoking, etc). The code runs in a dynamically provisioned, disposable mini-container that is fully managed by the service.

The true beauty off FaaS is its ability to pseudo-infinitely scale up and scale down...all the way to zero. This means that you can effectively ignore concerns about peak volume spiking and resource waste when volumes are low/dormant. Whether the function runs once a month or 500 times per second is irrelevant to the how you go about writing your business logic. Obviously the more you use it, the more you have to pay. But you also no longer pay for unused cycles nor do you need to do usage forecast planning.

Let's list what we don't have to worry about:

Resource Provisioning
Hardware maintenance
Software installation & maintenance
Networking
Distribution
Deployment
Horizontal scaling
Redundancy

Wow. Wait, this means I'm back to where I started 20 years ago as an engineer. I can see a functional need, code it, and that's it! It's obviously not that clear cut, but we've come awfully close. We've used technology to simplify a lot of the complexity that was introduced by ... well... technology.

What you need now in today's world are not engineers to build and maintain large technology infrastructures, but instead orchestration architects to design self-healing, self-managing eco-systems. You need problem solvers who are not enamored by the shiny new tool in front of them, but conductors who can hear the symphony amongst the pile of instruments.

Industrialization of the Cloud

All of this has actually been around for quite of while now. So why am I focusing on this "now" (mid 2017)? I believe the following critical thresholds have been passed:

Sufficient Competition

AWS (Amazon Web Services) is the clear global leader in the cloud space today. How the tech industry allowed a bookstore to take over half the internet still boggles my mind, but that is a story for another day. AWS has pioneered much of the cloud XaaS landscape and continues to add to its arsenal and is the defacto standard amongst many developers.

Microsoft Azure is a clear second place, leveraging it's traditional stronghold of back-end enterprise offerings as the proverbial foot-in-the-doorway to expand its footprint by convincing organization to expand and supplement their IT infrastructures through a hybrid cloud strategy. Despite the many stumbles Microsoft has made over the past decade, they seem to have done a surprising good job creating a very competitive cloud offering.

Google Cloud is a surprising distant third place. They seem to have really struggled in capturing this market, failing to differentiate themselves after being late to the party. But it appears they may be playing a long game focusing their efforts on things like AI / machine learning.

Having sufficient competition is important as it helps keep pricing in check and there's always the warm-and-fuzzy feeling that in the worse case you could jump ship to another vendor (all-be-it easier said than done). Although each vendor's cloud offerings differ slightly in the details, they seem to have finally all covered the basics:

Compute
Storage
Secure Networking
Messaging
Backend Logic Processing
Load Balancing
Log Management
Monitoring
API Management

Global and Regional Coverage

One of the dirty secrets that cloud vendors don't let you know is that not all their services are available globally. You receive a flashy announcement about a new service being offered only to find out later that it's only available in Virginia...with no concrete timeline of expansion... Being in the financial space, nearly all of our target customers are either multi-national, global organizations or are located outside the United States.

The leading vendors finally have sufficient expansion of their core services into enough regional markets that latency, security, and redundancy concerns can finally be addressed to meet the needs of financial institutions.

In addition, the pace of recent expansion, especially in 2017, seems to indicate a more of a "invest and expand to meet increasing demand" mentality more than a "let's test the waters" mentality. This is purely the author's impression based on observing the rate of certain service expansions.

Do what you do best (and make sure your partners do too)

The beauty of the cloud is that it enables companies to focus on what they do best, whatever that may be.

If you have a large organization managing IT resources: Is that what you do best? Is that the DNA of your company? Is you staff passionate about it? Are you good enough at it that you do it better than Amazon, Microsoft, and Google? More than likely the answers are no to most of these questions.

If you work at a bank, you already know all of this. Moving to the cloud has been a mandate already for the past 3 / 5 / 10 years. The message is nothing new. It's just not that easy. So part of your strategy includes partnering with vendors with cloud solutions.

But have you really asked how cloud ready your vendors are? Their solution may be "on the cloud", but:

Is that just a euphemism for "someone else's computer" circa 2007?
Are the underlying platform services scalable and self-managed?
Are the business components scalable and self-managed?
Is the resource orchestration scalable and self-managed?
Will the vendor pass the cost of unused resources down to you?
Is the architecture dynamically scaling or is it just sized to a finger in the air estimate?
Are you going to have to manage all or parts of this yourself?
Are you just paying them to manage all of this on your behalf?
Are they passionate and good at managing IT infrastructures?
Do they practice what they preach and develop and operate on the cloud?

Is your vendor really Cloud Native?

Conclusion

This is an exciting time for organizations looking to really innovate and solve interesting challenges. Today's cloud allows us to focus our energy on problems that interest us rather than solving necessary evils.

The strength of a company should be measured by their vision and the intensity of their passion, not the size of their organization. A 5 person company that uses AWS has the backing of a 200,000+ employee organization. The size of the one's code base used to be a measure of depth, maturity, and robustness. In a world where infrastructure has been commoditized and frameworks open-sourced, the code base size is more a measure of the size of your liability in terms of maintenance and QA.

Banks should seek out partners, not vendors. You are in it together. Have you asked your prospective partner the tough questions? Are they asking you to take a leap of faith with your operations that they themselves are unwilling or incapable of taking? With the proliferation of open-source and the maturity of the cloud, in today's environment, the value of a solution comes from its vision and service orchestration, not the software.