Platform-as-a-service (PaaS) is a type of cloud computing offering in which a service provider delivers a platform to clients, enabling them to develop, run, and manage business applications without the need to build and maintain the infrastructure such software development processes typically require.
Because PaaS architectures keep the underlying infrastructure out of sight of developers and other users, the model is similar to the concepts of serverless computing and function-as-a-service (FaaS), in which a cloud service provider provisions and runs the server and manages the allocation of resources.
Consider sports betting. Today, many bettors use known and published statistics, mathematical models, and other relatively primitive tools. The idea is to gain a small advantage.
Now let’s look at the world of technology. With the advent of IoT (Internet of Things) and edge computing mashed up with cloud computing, as well as access to all relevant information needed to determine the outcome of a sporting event, we could find a 90 percent success rate for those who know how to leverage cloud technology, data, and machine learning as a force multiplier. What Vegas casino would take a bet knowing there’s a 90 percent chance of paying out?
Of course, cloud computing, data science, and AI are the game changers here. Although we’ve always known how to do this sort of stuff in theory, the needed compute, storage, and AI was either not yet invented, or more likely out of financial reach. This is no longer the case.
Building IT software isn’t always the most secure process. The reason for this is simple economics. Companies can’t always afford to build in the security features software needs to be secure.
Let’s walk through a typical IT software project.
As the IT software project is planned out, the security of the software and the data the software contains is accounted for. But after the initial design of the software comes budget planning. There’s almost a 100% chance that the budget requested by the developers isn’t going to be approved by management. Management typically approves somewhere from 50-80% of the requested budget. This means features need to be cut. The business unit that requested the project will want to keep most if not all of the features they requested. That means the development team is going to need to find somewhere else to cut. Something has to give. In typical cases, the best options for securing the data and various security tests are going to be cut. This means that data that was going to be securely stored encrypted will likely now be stored in plain text. Security testing on the software isn’t going to be done at all, or if it is, it’ll be scaled way back.
While these types of cuts are not uncommon, as IT leaders, we need to make the business case for investing in enhanced security. We need to demonstrate that budget cuts in security end up leading to software that’s less secure than end users deserve. From a business perspective, this leaves the company open to potential data breach issues and the remedies that the states and countries the software is operated in are subject to. In the United States, if the software customers are in California or Massachusetts, there are some data protection laws in place that cover data breaches and data encryption.
The issue with data breaches is that you can’t fix the cause of the problem after the fact. Once customer data has been released to unauthorized parties, it doesn’t matter how much money the company spends or what they do to improve the software to ensure a breach doesn’t happen again. At this point, it’s too late—the customer's data has already been breached, and it’s in the hands of people that shouldn’t have the data. There’s no getting the data back out of the public eye. Once it has been released, there’s simply no putting the genie back in the bottle.
As IT professionals, we need to be building software that isn’t easily breached so customer data isn’t released. The fact that in recent years we’ve heard about problems like databases having blank passwords with millions of customers information sitting in them or files sitting in cloud services with no security is just inexcusable.
While budget will always be a major consideration, security also needs to be a driving factor as we consider software development. We shouldn’t have databases without passwords—it doesn’t matter that the default is no password. We shouldn’t have cloud-based file shares with millions of customer records sitting with no security. Once these breaches happen, there’s no getting the data back.
We have to build more secure platforms and software that don’t have simple, easy-to-correct issues in their configuration. The more we can ingrain this thinking into our organizations, the better off we all will be.
Over the past few weeks, I've written a lot about hybrid IT and its benefits. New tools, new technologies, new skillsets. Hybrid IT is still new to a lot of companies, and you might be wondering how to get started. Below are some areas to look into as you think about your own hybrid IT journey. There are a lot of traditional services you can transfer to the public cloud as a starting point.
Backups and Archive
Backups are a great way for companies to dip their toes into the hybrid IT pool. Tapes are cheap and hold a ton of information...but they're tapes. They can fail from the media becoming corrupt and need to be tested regularly to confirm their reliability. Rotating tapes offsite is a good practice, but takes discipline and good organizational skills to keep track of the many cataloged tapes. Transferring tapes pose a risk during the window of transit. During transfer, a tape could be damaged or stolen. Managing backups can be a real nightmare with its decentralized practice. Companies might have multiple remote sites small enough to not warrant a system's operator, and instead require an office manager to switch out tapes. Time to restore data can be a lengthy process as technicians need to retrieve tapes from offsite locations, re-catalog the data, and determine if the correct tape was retrieved.
Instead, look at using the public cloud. Most backup software vendors today recognize an object store as a data target. Configure the software to send test data to the public cloud and start experimenting. See how you can exchange tape rotation for data life cycle management. Instead of physically moving tapes around, in the cloud, set policies to automatically move data to a lower storage tier after so many days to help save money. Move the data to its lowest tier for archiving where data can be recovered in minutes or hours, depending on the cloud provider. Data at rest can be encrypted with your keys so the only one that can read the data is your company. No more having to transfer tapes to an offsite location and worry about theft or damaged media. The public cloud allows you to send to not just one region, but to multiple regions. If you're worried the U.S. west coast will go down, send your data to a different continent. Stop worrying and managing physical media. Reduce your administration work to focus on areas helpful to the business.
Infrastructure as Code
So many vendors today provide their APIs to allow for custom configurations. Being able to hit an API or use a software development kit (SDK) speeds up the provisioning process and provides a living, breathing, shareable document. I'm all about reducing the learning curve. It's much easier for me to understand new technology by mapping it back to something I already know and recognize the differences from there. Learning a new language like infrastructure as code (IaC) and learning how infrastructure in the public cloud works at the same time draws out the learning curve. Instead, focus strictly on IaC.
IaC is a great flexible tool that can be used to provision workloads from a number of providers, including on-premises data centers. Instead of using native tools built inside your data center to deploy workloads, use IaC to deploy them. Understand the syntax and how it abstracts the underlying infrastructure. Get a feel for the shift from manually managing workloads to managing code as infrastructure. Understand the pros and cons. Learning one new technology and understanding how it works using traditional infrastructure helps pave the path to when the organization is ready to consume public cloud resources.
This might be obvious, but it's a good reminder. Start small. Don't feel like you have to pick the hardest problem to fix with the public cloud. Use a new project as a potential starting point. Instead of reviewing traditional data center technologies, cast a wider net and invite some vendors who only live in the cloud. Understand the differences and compare them to the needs of the business. When maintenance is coming due on a piece of equipment, think outside the box and question if this is something you need to continue to maintain. Is this piece of software or hardware critical to my business and can I offload the responsibility to the public cloud?
The public cloud makes it easy to transfer and grow a lot of traditional infrastructure technologies. Once people get a taste and see how easy it is to scale and manage, they rush in. They find out managing cloud infrastructure is different than traditional infrastructure. Not only is the cost structure different, but not having to access the lower layers of the stack makes people nervous and requires a lot of trust. To gain trust, move mundane tasks not adding a lot of value to the business. Control what initially goes into the public cloud to better understand how the cloud functions and know the cost structure around their services. Reduce the learning curve and add on pieces with which you're unfamiliar.
Public cloud and private data centers are on a collision course. It's better to start now and grow familiarity and trust before you're forced.