Infoworld’s outstanding cloud computing blog is written by David Linthicum, a consultant at Cloud Technology Partners and a sought-after industry expert and thought leader. His Infoworld blog is exclusively devoted to cloud computing and updated frequently.
It’s Monday morning and you have another letter of resignation on your desk. This time from a woman who was doing performance monitoring and cloud-system tuning. Last week it was a database operations administrator, and two more from the cloudops team quit the week before.
What happened? The cloud was supposed to make things easier. Are you underpaying or overworking, or is there something else that is harder to fix?
The fact of the matter is that cloud operations teams are going to be abused during the next one to six years. There is very little understanding as to how the jobs will morph, and we grossly underestimated how complicated and challenging the cloudops roles would be.
Microsoft is previewing an open source extension to its Visual Studio Code editor for building full-stack web applications. Called Microsoft Web Template Studio (WebTS), the extension is intended to make it easy to build a cloud-based web app.
Developers can use WebTS to generate boilerplate code for a web application, choosing between different front-end and back-end frameworks, Microsoft Azure cloud services, and pages. Key to the tool is a wizard to generate an application as well as a READMe.md and provide instructions on use.
Kubernetes has become the project to turn to if you need container orchestration at scale. The open source container orchestration system out of Google is well-regarded, well-supported, and evolving fast.
Kubernetes is also sprawling, complex, and difficult to set up and configure. Not only that, but much of the heavy lifting is left to the end user. The best approach, therefore, isn’t to grab the bits and try to go it alone, but to seek out a complete container solution that includes Kubernetes as a supported, maintained component.
Here I’ve listed the 9 most prominent Kubernetes offerings—what amount to distributions that incorporate Kubernetes plus container tools, in the same sense that various vendors offer distributions of the Linux kernel and its userland.
GitHub has introduced the GitHub Package Registry, a package management service integrated into GitHub that allows developers to publish private or public packages next to their source code. GitHub Package Registry is available now in a limited beta release.
GitHub Package Registry provides downloads backed by GitHub’s global CDN. Packages can be hosted privately or publicly and used as dependencies in projects. Integration with GitHub enables users to utilize the familiar GitHub interface to find public packages on the site or private packages within the user organization. User and team permissions can be applied to code and package management.
You need a public cloud-based relational database to support a new application. You submit a request, not directly to a specific cloud provider, but to an internal cloud broker. This is a system that looks at your submitted requirements and picks the best relational database fit for the lowest cost and the highest SLAs (service-level agreement).
What’s more, these brokering systems can operate at an API level, allowing applications to provision coarse-grained or fine-grained resources, through the broker, with the simple invocation of an API. This can be done on the fly from within the application.
Graph databases, such as Neo4j, Apache Spark GraphX, DataStax Enterprise Graph, IBM Graph, JanusGraph, TigerGraph, AnzoGraph, the graph portion of Azure Cosmos DB, and the subject of this review, Amazon Neptune, are good for several kinds of applications involving highly connected data sets, such as providing recommendations based on social graphs, performing fraud detection, providing real-time product recommendations, and detecting incursions in network and IT operations. These are areas where traditional, relational databases tend to become inefficient and slow because of the need for complex SQL joins operating on large data sets.
When it came to whole industries closing their eyes to the rise of cloud computing, healthcare companies once comprised my biggest group of deniers. Most would not even take meetings, even though the scary public cloud held previously unattainable solutions for them. Now healthcare IT is no longer afraid of cloud computing—on the provider or payer side.
Microsoft has starting referring to itself as a three-cloud company. There’s the Xbox gaming cloud, Microsoft 365 productivity services, and, first and foremost, Azure. Number two behind Amazon Web Services, Azure is a hyperscale behemoth, rolling out service after service at a rate that’s hard to keep up with. That rapid cadence is even more visible during Microsoft’s three main developer events, and you sometimes have to delve into the flurry of announcements to understand the key elements.
Performance issues went away after we migrated our applications and data sets to the cloud, right? That has not been the case. Here’s just a few examples of why.
Most performance issues are traceable back to the application and to the hard fact that the applications must be redesigned and rebuilt to deal with the problem.
Database response time is a frequent performance issue and often requires a redesign or even an entire change of the database model.
Cloud platforms such as Linux and Windows Server often have the same performance limiters as their on-premises versions, including use of memory, user interface management, and external communications.
This list could go on for pages. By now I assume you’re sold on the idea that performance must be managed in the cloud, and that the solutions are not typically easy. You need a strategy to approach cloud computing performance management. Here are a few key ideas to get started:
It’s always been an issue—those who look at IT architecture as something that exists to serve a single application or small systems domain. These days many organizations fail to select a cloud technology to serve enterprise IT as a whole. They deal with a series of tactical application cases that all have one-off cloud architectures. Do that 20 to 30 times, and you’ll have a real problem.
The result is predictable. Cloud promised to lower costs and increase agility, but you’re facing a complex mess of cloud technologies built by one project after another. Things are difficult to change, and the value cloud was supposed to bring isn’t there. Moreover, toss the keys to those in CloudOps and you’re likely to see them fall down from the number of moving parts and heterogeneous complexity they are attempting to operate.