CHAPTER 3
The Cloud

Picture illustration depicting the upcoming technology of cloud concept in financial businesses.

Run! The cloud has become self aware!

Unless you have been living under a rock, you probably have heard someone somewhere mention the cloud. Usually in the context of “that freaking cloud,” in reference to trying continuously to delete a file only to have it mysteriously reappear, or, “The cloud is the greatest thing ever,” uttered by a data center engineer who can now set up an entire system in minutes instead of weeks or months. Whatever the context was, I am sure that you recognized this was an upcoming technology and took note of it or asked a few questions to gain knowledge about it. From there, you likely made some snap decisions about the cloud based on your years of experience with services that have been run outside the four walls of your organization.

The cloud concept isn't exactly new, and in the financial business it's been around for a while. I know many organizations that outsource their ATMs or credit-card processing to what could be considered a cloud in today's terms. I have also seen many organizations move these services in house because of service issues, or a perceived lack of control of the service. I believe that by and large, these experiences have shaped the financial industries' overall fear of cloud-based services. Unfortunately, things can change, and sometimes we need to reexamine things before depending on our past experience to make a decision. The cloud fits into the category of things that we need to look at with a new pair of eyes. Let's start by defining what it is today. What exactly is the cloud? Maybe you have heard of Apple's iCloud, or maybe you saw an advertisement about a personal cloud. In terms of the financial business, what is the cloud?

The Financial Cloud

The easiest definition of the cloud is that the software you run and the files you access are no longer tied to your computer or workstation; instead, they exist somewhere that is very accessible via the internet. In the corporate context, the cloud often refers to moving infrastructure and services from the corporate data center to an internet accessible data center like Microsoft Azure, Google Compute, or Amazon Web Services. For instance, think about the email on your local desktop. For a long time (and maybe even it's still true at some organizations), email was housed in a company-owned data center. The emails would come in through the internet and then be stored on a server somewhere within the company. Someone in the IT group would be responsible for backing up this server or making sure it had the appropriate protection against email viruses. They would also be responsible for setting up new users, planning upgrades, and general maintenance of the email server. Finally, financial institutions would make sure the server complied with Sarbanes–Oxley and any other regulations that the industry needs to implement.

The software a person uses to access email is located on their local computer, and it communicates to the email server in their data center to get your email and to send your newly composed emails or replies. The situation I just described is the opposite of the cloud. Everything is contained within the four walls of the organization.

Here is what a cloud version of email would look like: Email is stored on some hardware somewhere, but company employees wouldn't need to know where, or be concerned about how it gets there. In fact, their email could be stored on servers in a data center in Seattle on Monday but on Tuesday it could be stored on a data center in Kentucky. Wherever it is, the users don't have to worry about it. All they need to know is that their email works. The company hired to provide cloud email service would be responsible for knowing where the email is and making sure it gets to the right desktop. The same company would also be responsible for maintenance of the systems that are collecting and storing the email, complying with regulations, backups, and anything else that must be done to maintain your email service. Instead of accessing email via software stored on a local PC, employees would likely access their email by executing software over the internet.

Why would a company do this? Why would it outsource its email to some other service? After all, email has become a critical component of all business. (Don't believe me? Unplug your email server and watch what happens.) It seems crazy to lose control of it to a service with people you don't know. The answer to this daunting question lies in scale, aggregation, and efficiency.

Picture illustration depicting how the cloud-based e-mail could be stored on servers in a data centre.

Wow, I didn't think anyone was still using email…

The cloud-based email service provider can scale very easily. The email service has likely built out a very flexible infrastructure that allows them to do things like add storage or bandwidth on the fly. They can also easily expand the number of servers supporting the organization during busy times and then remove the excess servers during periods of low activity. If the servers were kept in house, the company would be forced to architect its email service to the greatest demand, even though that demand was only for a short period of time. Since the cloud bills are based on server usage, you only pay for what you use.

The cloud is also based on aggregation. In the case of email, a company is likely sharing servers, bandwidth, and support personnel with hundreds of other organizations. A medium-sized organization might have 2,000 email accounts on its server. While this might seem like a lot, the reality is that supporting 2,000 or 200,000 accounts is very similar in terms of the amount of work it takes for an email administration person. So, by sharing this person with other groups, companies are reducing their full-time employee count and, therefore, their overall ongoing cost to support email.

I would guess that an IT person reading this would think, “There you go. Best is talking about getting rid of <insert name of highly valued employees here> and replacing them with some idiots that I have no control over.” Think again. I would actually say that the best thing to do with your highly valued employees is to retrain them so that they can manage your cloud service—but with the time they recovered, they can be of use in some of the new technologies that are going to be at the forefront of banking soon, such as chat servers or Skype communication. Their experience will be valuable for these new channels, and without email to weigh them down, they will be free to leverage what they know to help make new channels a success.

Efficiency is also a great motivator to move to cloud services—let's say an organization is going to upgrade its entire email platform over a weekend. If they haven't been through this process before, it can be very stressful. Often, new hardware is purchased and the emails need to be migrated from one server to another, which can take hours. When everything is done and the new platform is in place, then there is the need to test the platform and make sure everything is working properly, including things like secure email, virus protection, workflow, and other critical features of the email system that employees depend on, day in and day out. However, in a cloud platform, one can easily provision new hardware, run the necessary updates and conversions, and then sit back and let the operators at the cloud service deal with the rest. Consider if they needed a new email server for a new division to test inbound sales emails with Salesforce. In the non-cloud situation, they would be responsible for building and deploying this system, but in the cloud they can provision a new system, test, and then simply turn it off when the team is done. One of the biggest slowdowns in new projects is often acquiring and setting new servers in a new environment. The cloud removes this issue from the equation by having infrastructure available on demand.

During my time at WRG and BIG, we have worked with both organizations that are all in house for their data processing and organizations that have embraced the cloud. The organizations that have embraced the cloud would finish a project almost two months earlier than the ones that were in house. This is because the in-house organizations had to purchase servers, have them shipped, then unbox them and get them on the network. After all of that was done, they had to be configured with the correct software and finally opened up to the implementation engineers via the internet so that custom home banking software could be installed. This could sometimes take months, whereas a cloud-based organization would go to their cloud console, click some buttons, answer some questions, configure security, and in less than a hour, they could make three to five servers available to our engineers for installation purposes. Any time you can turn months into hours, you need to pay attention to however it is being done. That said, the first time I experienced this, I immediately made it a point to reach out to the CTO of that organization and ask some questions.

What Are You Afraid Of?

Like everyone, I had fear of the cloud. Here are my fears, in order of magnitude.

It Is Hard to Control

Many organizations worry that they will have no control over their cloud-based processes and systems. Even worse, they worry that, as part of a huge cloud ecosystem, their concerns won't be important to the people who can effect change. What does control really mean in terms of a data center? For me, control meant being able to physically turn off a computer by pressing the power button if I wanted to, or unplugging the ethernet from a port if I wanted to or login in locally. Control also meant that I had someone who was accountable for these servers—a person who I trusted and who, if necessary, I could reprimand if there was a mistake. How do these things translate in the modern version of cloud software? Turns out, the modern cloud has many answers to this. First, you can actually “power off a system” or “unplug it from a hub,” and second, you can also work with service providers that will provide management of these systems effectively, giving you accountability.

It Is Insecure

Security is a huge consideration in the financial industry, and many people worry that the cloud can put sensitive data at risk. After all, companies might not know very much about the cloud provider's services, and they can't see the firewalls that are protecting them. This makes them doubtful that such security measures are even in place.

Even I have encountered this. Security was a huge concern because I was running data systems for a large financial network. What changed my mind was when both Amazon Web Services and Microsoft Azure became C2 certified, and offered a government ramp. Having some background in what it takes to meet these criteria from my security days helped me understand the protections that each of these groups had put in place. This by no means exonerates an organization from putting in all of the protections necessary and conducting the necessary penetration tests to ensure that their security is functioning. Also, this doesn't help if a company is writing applications that have inherent security flaws. In that situation, no amount of firewalls or other protections will save anyone from trouble.

I also discovered that organizations can deploy their own firewall systems in each of these cloud services, which was valuable information. Finally, how could I compete with Amazon or Microsoft in terms of the amount of security that they are able to afford versus my own organizations budget?

Data Will Be Shared with Others

This isn't one of my actual fears, but I do encounter questions about it quite a bit. One concept of the cloud is that an organization doesn't need to provision an entire server. It can share the computing resources with others in order to reduce cost. Many people have concluded that if you are sharing a server with other organizations and an application on that server is hacked (even if it isn't yours), then the hacker would gain access to everything on that server. Fortunately, the smart people at Amazon, Microsoft, VMware, and other companies that provide this sort of technology accounted for this and created systems that are walled off from each other even though they are sharing computing resources. The data itself are never intermingled in that all processes are executed in their own space, and all data are stored in their own secure data areas, without intermingling. I can see why people would think this, because before true virtualization existed, many web-hosting providers would share a server or resource in a way that did expose the other applications if someone could gain access to any of the applications on that server; however, this technology is not in use in the major service providers.

It's Unreliable

The number-one reason that people built their own data centers was because they had been involved in an outage while participating in a shared data center or some other service and the resulting loss of service cost money so as a result, they concluded the only way to ensure service availability at the level they could live with was to own the data center themselves. Once again, the big players like Microsoft, Amazon, and Google have thought of this. Each of them has spent enormous amounts of money building data centers around the world. In the new world of the cloud, a company can instantly transfer its entire service or server from, say, a data center in West Virginia to a data center on the West Coast. Even better, they could easily run their service in both places. This is something that would be very costly for a single organization to do by itself. As a result of these services, the cloud services have become very reliable.

It's Super Expensive

This is one I actually will agree with to some extent. However, it's not super expensive if you factor in building a data center, maintaining it and paying for electricity, as well as air conditioning and all of the other critical systems that are needed to run a financial data center. Nevertheless, I have found that when an organization first discovers the cloud, its people go a little crazy when they realize how easy it is to set up networks and systems—things start exploding in what I call SharePoint effect.

Anyone who knows me knows I am not a fan of SharePoint, but it's not SharePoint's fault; it's my own fault. One day, my team discovered Microsoft SharePoint and we decided to implement it. The next thing I knew, at every meeting someone would say, “I put it on SharePoint,” referring to a document or spreadsheet, and someone else would ask, “Which Sharepoint?”

The reason this happened is because I failed to see that a utility that was as easy to implement as SharePoint needed governance. I just saw it as a simple website that could help make things better. What I hadn't thought of was that it was so easy to set up that anyone, and I do mean anyone, would request one, and magically, it would appear. It got so bad, I had to ask them to color code the SharePoint services. This didn't seem like a big deal to the local users because they only used the one SharePoint site, but for cross-functional teams like accounting, or the executive group, it was a nightmare to even figure out what SharePoint site you were on. At one point, I actually caught myself saying, “Well, what we need is a SharePoint site to track SharePoint sites.”

It was like trying to put out a fire using more fire. The same thing happens with the cloud—a new server can pop up in no time, instead of taking hours to set up a network or getting approval to set up a new server. So, yes, the cloud can be expensive if you don't put some governance around it. You must treat it like buying a server or any other service, and make sure that your team understands how to use it. This includes setting up the ability to turn it off during off hours, or sensing use and having it grow during busy times. I believe that at the end of the day, the cloud can be cheaper, but only if properly governed.

There Will Be Staff Cuts

I have a theory about cutting people in IT. The theory is: Don't do it. If you manage to achieve a cost-saving factor, cutting heads isn't the best idea. Information technology is not like the call center, or a teller line where these folks have a single job. The information technology team is often well versed in the processes of other departments, and as such, they can be very valuable in the new and upcoming technology, I would suggest retraining them, learning distributed ledgers, implementing cloud-based programming (turning off and on servers to save money), or training them in artificial intelligence systems. These employees' inherent knowledge is valuable. Many times, they have many years of experience in your organization, so you must be very cautious about throwing this experience away. It might be easier to train them in a new technology rather than training an expert in new technology about your organization. They can also be transitioned to run outsourcing groups capitalizing on their experience and relationships within the organization to implement new services.

The Internet Could Go Down

There is some truth to this one. Organizations using cloud services are dependent on the internet. However, let's face it, this is a truth even if you don't use the cloud. If you don't believe me, go ahead and unplug the internet now and see what happens. The reality is that while the cloud does add to the dependence on the internet, I would argue that you are no more at risk than you are today. I would also argue that due to the redundancies mentioned above, in the event of a major outage, the cloud providers have a better chance of surviving a event like this than you do on your own and as a result your customers will at least be able to access your digital services.

It Is a Direct Expense

Keeping your storage services or servers in house can deceive the average CFO who is used to depreciating the hardware, software, storage, and network services associated with a project over three to five years, which, on paper, is seemingly favorable compared to the paying monthly fees for cloud services.

The biggest difference is the amount of overhead needed to maintain the infrastructure. This is often not factored into the “move to the cloud” equation. Also, I find it is unusual for an organization to factor in the disaster recovery or business continuity planning that was handled much more elegantly in a cloud services situation. Fully loaded costs will show that moving to the cloud is either a wash or cheaper.

A quote for Kirk Kordeleski former CEO of BethPage Credit Union in Long Island:

What about Our Data Center?

Here is the bad news: If a financial institution is running a system on a mainframe, it will likely still need its data center in order to run core processing or main general ledger processing. However, what I have seen in some industries is a concept I will call AirDC. It's sort of like AirBnB but using data centers instead. An organization with a data center could share it with other organizations that use the same processing systems or other platforms. This could reduce costs. However, it's likely that an organization will continue to need its data center, but it can reduce power consumption and licensing costs.

The Cloud Won't Conform to Regulatory Needs

I have heard the concern that the cloud doesn't provide enough control over where data are stored, and as a result, it may be stored in a geographic area that would make a financial services firm liable in the jurisdictions where we do business.

While this was once true, it is now possible to choose where data will be stored. Organizations have control over where their data are stored and processed. It's also important to note that custody of data can be directly related to where the data are decrypted.

The Cloud Kills Baby Seals

OK, this isn't true, but there are people who believe that cloud computing's carbon footprint will increase global warming and kill baby seals. Through my research, I have discovered that that the main players are all working very diligently to use clean energy for their data centers. Google data centers have solar panels on the roofs of their data centers. Microsoft and Amazon both have clean-energy initiatives. The reality is that it's more likely that a non-cloud data center is killing baby seals. The big cloud players are likely cleaner.

Types of Cloud Services

Now that we have talked through the main concerns, I would like to put a little more definition around the cloud to help you understand how you can use it. There are (at this moment) three main definitions of cloud services.

Infrastructure as a Service (IaaS)

IaaS, or infrastructure as a service, is defined as providing computing and network services over the internet. Here is an example: Let's say that an organization has a new fintech lending organization that it wants to work with, and you need to set up a sandbox for them to work in. A sandbox is a network of servers that has access to development versions of your internal platforms like your lending platform so that the fintech dudes can do their thing.

If companies use their local data center, they might have a virtualization server from VMWARE and would provision the servers and create a network for the fintech folks to use. They would still need to have the fintech providers log in to the local data center, probably using a VPN. This requires approval from an internal security group and then building a private network to keep them out of anything else. In the cloud model, you would be able to provision the server, the network, the firewall, and the VPN all as a service and then make the sandbox available to the fintech players over the internet.

The internal setup could take a few weeks; the cloud setup might take a few days or hours. The other important concept here is that the fintech providers are in India or the United Kingdom and, as a result, their time zones are very different. They are not working during the same hours as your support staff, and with this in mind, your IT team can program the IaaS to shut down the sandbox when it is not in use, thereby saving money and reducing security concerns (every hour the servers are turned off is a hour the server cannot be hacked). IaaS dashboards are quickly becoming the norm in the fintech industry.

Software as a Service (SaaS)

The best example of software as a service (SaaS) is Salesforce.com. Salesforce provides your sales team a database in the cloud. If an organization wanted to set up a customer relationship management (CRM) platform instead of buying or licensing the software, it would need to purchase the servers and have its IT team set it up. You would go to Salesforce.com and set up your organization with Salesforce.com. Your sales team would then use the web browser on their local PC or their smartphones to access the salesforce system and perform their duties. The beauty of this is that your information technology team is not responsible for upgrading or maintaining Salesforce; they are only responsible for making sure that the systems and devices the sales team uses to access the Salesforce.com website comply with the standards that Salesforce has set forth in their agreement. What this means is that the sales team can't be using Windows 95 running Internet Explorer 5. They will likely need to be on the latest operating systems and the latest browser technology to get the full benefit of the Salesforce product.

Platform as a Service (PaaS)

Platform as a service (PaaS) is the third and final category of cloud services that is offered. Here is my example of platform as a service: Let's say that a company is organizing itself around the technology services organization, and as a result the team has decided to develop its loan application process in house. The team has chosen to use the Microsoft Net software as their programming system and as a result, the software they design will need to run in a Microsoft environment. This means that the developers will need to have software to develop on. In Microsoft, this is called Visual Studio. They will also need a place to store their code, which can be done using Team Services.

Finally, when the software is done, the team will need to have a place to deploy it, and the licensing to support the number of people that will access their new loan application. This would be an application called Microsoft Server, which can also cost money. So at the end of the day, all in to support the Microsoft development your team is doing, it could be hundreds of thousands of dollars. This doesn't include the hardware and firewalls associated with the application. Nor will it include the environments that are needed to support the ongoing new application. By this I mean production, testing, and development, which are all distinct copies of each other meant for different purposes.

What is the answer to all of this? Microsoft sells all the aforementioned software as a platform services. This means a company's developers can use the platform to develop and it is automatically connected to their team services as well as their in-house environments. This frees the team to focus on the end result, which is the application. I could tell the same story using Amazon Web Services, Linux, and Java. Why is this important? One reason is because in the brave new world of development and innovation, sometimes projects will fail to produce the desired results and then when it is necessary to shut it down, companies are stuck with all the setup costs depreciating away on the books. The second reason is time to market, when your marketing, analytics, or sales team identifies an opportunity and your development team designs a solution to capitalize on it, you need to be able to move fast, build up, tear down, and make it happen. Waiting on servers and licensing can add months to a project. The final reason is that this allows your team to effectively outsource; this is going to be important in the new digital world of finances that is coming.

Major Players in the Cloud

There are many players evolving in the cloud market—too many to cover in this book—but I did want to talk about some of the major ones.

Amazon Web Services

OK, right off the bat you are probably thinking, Amazon? The same Amazon that sends me my dog food? Yes, that Amazon. Amazon had a problem to solve. Its internal projects that were supposed to finish in four months were taking twice as long as they should. Amazon realized that its network engineers were spending far too much time with its application engineers trying to coordinate infrastructure and other details. So Amazon decided to build a framework that could be used for all of its projects. After the framework was designed, Amazon realized that others could use it. So it started Amazon Web Services in 2006. As of this writing, Amazon Web Services provides a platform for hundreds of thousands of businesses in 190 countries around the world. Amazon has data center locations in the United States, Europe, Brazil, Singapore, Japan, and Australia.

Microsoft Azure

Microsoft Azure was announced in 2008 and released in 2010, mainly in response to Amazon's offering. It was originally called Windows Azure, and eventually became Microsoft Azure. Azure provides a console application that allows administrators to easily setup environments, implement network changes, and take advantage of Microsoft services such as the business intelligence platform or artificial intelligence platforms.

Google Compute Engine

Google Compute Engine (GCE) was introduced to the world in 2012 and is considered an IaaS solution. Similar to its competitors, it provides the ability to virtualize and run operating systems such as Linux, Microsoft, and BSD. GCE provides access to Google services such as its search engine, Gmail, YouTube, and their AI services via its cloud offerings.

Commonalities between Each of These Platforms

Each service has similarities. They all support multiple operating systems, and billing for all three is reduced to a number that represents the compilation of computer resources (power, hardware, storage) that are called units.

Each platform also sells and supports its distinctive tools. For instance, in AWS, storage is powered by its proprietary storage platform called S3. Google has baked in some of its products to make it easier for developers and fintech providers to use its platform.

All three have multiple certifications such as SOC 3 (Service Organization Controls), PCI (Payment Card Industry), DSS (Data Security Standards), and DOD (Department of Defense) impact level 5 provisional authorization.

How to Choose?

Much of the decision is going to depend the prevalent architecture and internal expertise within your organization. For instance, if your organization uses Microsoft products for both development and to service the front-line employees, then your obvious choice is Azure. Conversely, if your organization runs on open source Linux software and your internal expertise is in the Linux platform, then Google Compute Engine or AWS are probably a better choice for your cloud. You can also use both platforms (which is as a hybrid cloud), but don't expect them to easily communicate with each other. The current cloud environment is very competitive, and as a result, there isn't a huge incentive for Amazon to make it easy to connect your AWS cloud to your Microsoft Azure cloud.

Capital One in the Cloud

So, have any major banks moved to the cloud and talked about publicly?

Yes, Capital One publicly stated in 2015 that it intended to move most of its data processing services to Amazon Web Services:

Capital One has made it clear that this is not an experiment, it's a conscious strategy based around the reasoning that the winners in the banking industry will be the strongest technology players.

Strategies for Moving to the Cloud

I find that the cloud is a very black-and-white subject with in financial organizations. FIs either find the cloud to be abhorrent or embrace it. I believe there is middle ground. Some things can be safely moved right now to the cloud that would improve security as well as your ability to execute. I call this approach to cloud migration the hybrid cloud approach. The hybrid approach involves only moving nonproduction platforms to the cloud. One example would be a development or test environment. It also includes connecting the cloud to your local infrastructure.

Regardless of whether you develop software in house or purchase software from vendors, your organization will have a place for these entities to test out their new releases or to do their initial installations. Having been on the other side of the process for many years, I know that just getting connected to a financial institution test or development environment can be an incredibly painstaking process. Some organizations will demand a VPN be used, and so all users must have VPN software installed on their employee's equipment. In fact that's what vendors talk about when you aren't around. They say things like, “OMG, dude, did you have to give blood to get connected to such and such?” and, “It took us six months just to get the test environment up.” Some organizations insist that all development be done on virtual environments, and these environments must be set up inside of the organization. Another issue is that if the environment doesn't exist—say, in the case of a new application—then the FI will often order new equipment, and that can add months to the project. The cloud is a perfect place to put this sort of environment. The test systems shouldn't contain any actual real customer data that should overcome any security objections, and since the cloud isn't connected to the organization's backbone, it effectively creates a walled garden for the vendor. This should reduce the security requirements to access the environment. It is far easier for the IT staff to provision servers and other services (like a mail service or phone service) in the cloud since it is not connected to any production systems. Finally, a nonproduction system doesn't need to be on 24/7 and can be scheduled to shut down during off hours, which will also reduce cost. This approach increases security, reduces cost, and increases time to market. In general, every production system has a mirror-image test system and development system somewhere in your infrastructure. Identifying each of the systems and moving them to the cloud could prove to be the perfect first move for an organization considering using the cloud.

There is also an evolving new option that would allow you to take advantage of some of the services of the cloud inside your own data center. Microsoft has announced azure services that can be run inside the four walls of any data center, or data centers. This allows the advantages of instant provisioning, scheduling resources, sharing resources, and migrating between data centers instantly. There are some limits to this approach; your options for data centers will be limited to your own data centers. However, this approach can also be synchronized with Microsoft Azure Cloud, allowing your data center to be integrated with the cloud. I would imagine that organizations that are resistant to the cloud will avoid this feature; however, for those who embrace it and have a significant investment in a data center, this could extend the life of that investment.

Here are the primary reasons for a financial institution to consider moving to the cloud:

  • Leverage cloud services to minimize replacement costs of current IT infrastructure.
  • Refocus the technology team in supporting the front-line and back-office staff and business-focused projects.
  • Assign the day-to-day administration and management of network and server equipment to a third-party provider.
  • Implement a redundant, fault-tolerant, highly available data center and eliminate single points of failure on networks, server farms, communications systems, core platform, and enterprise storage.
  • Provide capability to have quicker flexibility in our IT infrastructure.
  • Enforce best-practice perimeter and internal information security systems to preserve confidentiality, integrity, and accuracy of assets.
  • Effectively support business continuity and survivability of corporate facility and all remote branch offices.

NOTE

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset