The 3 biggest mistakes to avoid in cloud migrations

I’ve heard many times that if you’re not making mistakes, you’re not making progress. If that’s true, we’re seeing a lot of progress made this year in cloud migrations!

Here are the three errors that I see enterprises repeatedly committing.

Mistake 1: Moving the wrong apps for the wrong reasons to the cloud. Enterprises continue to pick applications that are wrong for the cloud as the ones they move first. These applications are often tightly coupled to the database and have other issues that are not easily fixed.

As a result, after they’re moved, they don’t work as expected and need major surgery to work correctly. That’s a bad way to start your cloud migration.

Mistake 2: Signing SLAs not written for the applications you’re moving to the cloud. When I’m asked what the terms of service-level agreements should be, the answer is always the following: It depends on the applications that are moving to the cloud or the net new applications that you’re creating. Easy, right?

However, there are many—I mean many—enterprises today that sign SLAs with terms that have nothing to do with their requirements. Their applications use the cloud services in ways that neither the cloud provider nor the application owner expected. As a result, the cloud provider does not meet expectations in terms of resources and performance, and the enterprises have no legal recourse.

Mistake 3: Not considering operations. News flash—when you’re done migrating to the cloud, somebody should maintain that application in the cloud.

This fact comes as a surprise to many; in fact, I get a call a week about applications that are suffering in the cloud. Those callers’ organizations assumed that somehow, someway the cloud would magically maintain the application. Of course it won’t.

Remember that you have ops with on-premises systems, and you should have ops with cloud-based systems. The good news: The tasks are pretty much the same.

I hope you won’t make any of these mistakes, but chances are good that you will. If you must make them, I hope you’ll recognize them more quickly thanks to this list and recover sooner.

Powered by WPeMatico

Think again: Data integration is different in the cloud

It’s been nearly 20 years since I wrote the book “Enterprise Application Integration,” yet after all that time data integration remains an afterthought when it comes to cloud deployments. I guess that’s par for the course, since security, governance, monitoring, and other core services are often afterthoughts as well.

When moving to the cloud, enterprises focus on the move itself, rather than on what they need after they get there. Although this may be a common plan, it’s not a best practice.

Data integration is essential because you’ve rehosted some of your data on a remote cloud service. The inventory system that’s stilling running on a mainframe in the datacenter needs to share data with the sales order system that’s now on AWS. In other words, your data-integration problem domain is now bigger and more complex.

The trouble is that traditional approaches to data integration, including traditional data-integration technology providers, are typically no longer a fit. Even data-integration technologies that I’ve built in the past as a CTO would no longer be on my short list of data-integration technologies that I would recommend today.

That’s because the use of the public cloud changes how you do data integration. For example, you need a much more lightweight approach that can deal with more types of data.

Also, having the data-integration engine in the enterprise datacenter is no longer efficient; for the same reason, it should not be placed at a cloud provider that has centralized access to all systems that are being integrated.

Cloud-based data integration also requires different types of security and governance services. Although most data that moves from system to system in an enterprise is not encrypted, you need to encrypt pretty much everything moving to and from systems in the cloud.

The list goes on.

The result is that cloud data integration is not your father’s data integration. It requires different approaches and different technologies. Although the old guard has done a pretty good job of cloud-washing their datacenter-centric solutions, you need to look beyond them, at data-integration technology that was built specifically for the cloud.

Powered by WPeMatico

Don’t let cloud providers kick you off like United

As everyone knows, last week a United Airlines passenger was asked to deplane because the airline overbooked and needed his seat for a staff member, then was dragged off the plane by Chicago airport cops when he refused to leave. Yes, the passenger didn’t follow the rules, but the situation ultimately was United’s fault.

Believe it or not, what happened at United is an object lesson for any business that signs up for cloud services. I’ll explain shortly.

Back in 2007, I boarded a United flight that was overbooked, and I was asked to deplane as a result. It was inconvenient and humiliating. However, I didn’t go limp, and the cops didn’t drag me bleeding off the flight.

Most airline employees, whether at United or another carrier, robotically follow procedures and rules. In the case of last week’s passenger, who didn’t believe he could be forced off the flight because he had a paid ticket, the employees didn’t try to solve the problem, such as by asking for a volunteer or trying to solve the passenger’s concerns (he had patients to treat the next day back home). They did what the procedures said and called the cops.

The airline adhered to the contract of the ticket purchase, which basically give passengers no rights. But being legally correct isn’t the point. It’s all about how you treat customers when the system stops working correctly for them, even if that unwanted behavior is “legal” or within the contract.

The contracts you sign with public cloud providers are similar to the contracts in an airline ticket: They’re one-sided in favor of the provider, with many limitations and the right for the cloud provider to kick you off its cloud. When you operate automated systems at such scale, you can’t deal with all the desires and special circumstances of each customer. At least, you don’t think you can, which is why cloud and airline contracts are so one-sided.

IT organizations haven’t yet experienced the cloud equivalent of being asked to deplane. But wait until enterprises have migrated 25 to 40 percent of their workloads to the cloud—and begin to stress the resources of the public cloud.

At that point, we’ll see enterprises make more demands on their public cloud providers, and we’ll see the providers push back, citing the contracts and even kicking some enterprises off the public cloud per those contract’s terms.

But as in the case of United, cloud providers that mindlessly implement their contract terms (and kick enterprises off their cloud services for whatever reasons the contract permits) won’t be in the right. It makes no difference what the rules say: Public perception will play a huge role, and the cloud provider will lose. The backlash, and major stock price hit, that United experienced last week is a cautionary example.

Enterprises need to understand they have leverage, even with the one-sided cloud contracts they’ve signed. An enterprise’s opinion of its cloud provider is powerful in and of itself, and enterprises that have issues with providers can go public with those issues—usually they find that the issues quickly go away as the provider does damage control, no matter what the contract says.

The new world order is one of perception. Cloud providers can try to fight it all they want, but even if they win, they’ll lose in the end. Enterprises should be aware of their new power and use it when needed.

Powered by WPeMatico

Your cloud choice: Succeed slowly or fail fast

If you want proof that what I’ve been advising for years is true, check out this research on cloud computing from The Register: Planning pays off when it comes to cloud migration and deployments.

The Register found that most companies don’t yet have meaningful cloud adoption or have truly embraced the idea of the cloud-first enterprise. The Register’s report also shows that cloud adoption has been gradual over the past five years—it didn’t find the market “explosion” that many in the press have been writing about.

Finally, the report recommended that you get your internal systems aligned with public cloud systems. That means planning better cloud management and application, data, and platform integrations.

The report underscored what IT should already understand: Cloud computing is an incremental process for most enterprises. It takes time to get the resources aligned and more time to do something meaningful with them. My rule of thumb is that enterprises typically underestimate the amount of time by a factor of two.

Cloud migrations and deployments are hard—or at least harder than most people believe. Why? Because cloud computing is systemic change in how we do computing. As you move up to 30 years of internal systems to the cloud, you’d better know what you’re doing.

Unfortunately, many enterprises, especially in the United States, are run by short-term thinkers, egged on by the rosy scenarios painted by the tech press, cloud providers, and, dare I say, analyst reports.

When they decide to move to cloud, it’s within an aggressive timeframe that’s largely unrealistic. They’ve set themselves up for failure.

No surprise then that most enterprises fail to meet their own expectations. It’s those that spend the time doing upfront planning that typically do the best, fall short the least, and even sometimes meet or exceed their expectations.

My advice remains consistent: View this as the greatest IT shift since the initial automation of systems in the 1970s and 1980s. There needs to be a great deal of planning and understanding that occurs before you make the move. Only then can you find your path to success. Better a slower path to success than a fast one to failure.

Powered by WPeMatico

Boycott ISPs that abuse privacy, net neutrality

After Congress repealed the FCC’s broadband privacy rules two weeks ago, new Federal Communications Commission chairman Ajit Pai promised that the personal information they give to their ISPs would continue to be, well, private. Indeed, Pai said that he planned to work with the Federal Trade Commission to police ISPs around privacy issues.

However, many believe that this will not only fail to provide effective broadband privacy protections, but will also come at the cost of removing the FCC’s net neutrality rules. As you may recall, net neutrality prohibits ISPs like Verizon and Comcast from picking winners and losers on the open internet. Indeed, we could be heading for a day where the FTC actually won’t be able to regulate ISPs at all.

At the end of the day, these changes are really about placing trust in the government and the ISPs that they won’t deny or throttle specific internet services, including cloud services, over others. It’s also about placing trust that our use of cloud services or other internet services won’t be monitored for whatever reason. Trust us, right? 

As cloud computing moves toward a trillion-dollar market, we are facing the fact that the open internet is how these cloud services get to users. They typically flow through an ISP, and that ISP’s ability to deal with those services equally is important to enterprises, not only in the United States but all over the world.

Moreover, if ISPs collect data to use for their own purposes or sell to others, enterprises could find that down quarters, pending lawsuits, and even unannounced successes are easy to figure out because that internal information has been monitored by the ISPs and sold or hacked.

Enterprises would have to encrypt everything—and I mean everything—to keep this data away from ISPs. That will cost millions of dollars in terms of system changes and lost performance.

I hope ISPs are not stupid. But enterprises should avoid ISPs that stupidly take advantage of the lack of net neutrality or the removed legal constraints around privacy.

We’re banking on ISPs to regulate themselves, while paying them billions of dollars in broadband fees—both direct and indirect. ISP/cloud customers need to hold the ISPs’ feet to the fire to ensure that they get good ISP service, the ISPs do not favor one cloud provider over another, and most important, the ISPs don’t become Big Brother.

Enterprises should kick abusive ISPs to the curb. I’m pretty sure the government won’t.

Powered by WPeMatico

You need your ‘cloud brain’ more than ever

How we do IT is changing. As it changes, we need to alter the way we think about IT. I like to call that new thinking as having a “cloud brain.” 

So what the hell is a “cloud brain?”

A few core attributes include the following:

  • The ability to stop looking at all workloads as things that must exist in a corporate datacenter. Platforms can reside anywhere: colocation providers, cloud providers, in your datacenter, or on your phone for that matter. Compute is what’s used where you can find it at the lowest cost, and it matters not if you can touch it.
  • The ability to deal with security as a systemic concept, not a bolt-on. The traditional approaches to security don’t work in the cloud. You simply can no longer focus on tactical security that surrounds specific workloads. Instead, you must concentrate on systemic security that’s pervasive to everything you do.
  • The ability to focus on how technology can enable the business, not the other way around. Guess what? IT serves the business, and if you forget that fact, you’re not likely to recover. When IT doesn’t think with its “cloud brain,” it becomes a liability for the business, and the department needs—and often gets—a reboot.
  • Unlimited scalability. Scaling was never hard. What was hard was buying the hardware you needed to do accomplish it. Cloud computing means scaling is only a few clicks away, which removes the risks as well as the costs.

Things are different today than they were even a year ago. Yet many people in IT don’t have “cloud brains.” They think in terms of limitations, not innovation. They consider cloud technology to be a tactical tool.

As time goes on, people who don’t think with a “cloud brain” will find themselves on the sidelines. So … how is your “cloud brain” coming along?  

Powered by WPeMatico

Coping with H-1B limits: Distribute your talent instead

Whatever you may think of the limits put on H-1B work visas for U.S. jobs, it’ll likely be the law of the land for the next four to eight years, so enterprises that use high technology need to adapt. My advice: Distribute your technology talent globally, with help from the power of cloud computing and other technologies.

It was not so long ago that you had to be physically near the systems to build and maintain them. These days, however, systems are pervasive, and your location has little impact on your ability to design, build, deploy, and operate business systems. 

What puzzles me is the number of enterprises that have systems running all over the world, thanks to cloud computing, but that require people to be located in the corporate offices. My advice, again: Get good at distributing your people, all over the world if needed, like we’re getting good at distributing IT resources, thanks to the cloud.

Get good at distribution: data, development, processes, applications, and yes, people. I routinely run teams that are multinational, and the use of cloud computing becomes the common thread that allows distributed teams to be successful. In fact, I believe they’re more successful in such cloud-connected teams than if you made them show up to an official corporate cubicle each day. 

There are other benefits in addition to using talent wherever it happens to be. If being green is a goal, forcing people to sit in, say, Highway 101 traffic in Silicon Valley undermines that effort. Moreover (and most important), those two or more hours a day could be used much more productively.

When I give such advice, I get pushback concerning legal issues around use of labor, particularly the ability to monitor and evaluate employees. In other words, it’s really about control.

But the bottom line is if you can trust your applications and data to run outside your walls as they do in the cloud, you should easily be able figure out how to gain the same trust for your people.

Powered by WPeMatico

AWS is moving beyond IaaS and PaaS

Last week, Amazon Web Services launched Amazon Connect, a cloud-based contact center service. The objective is to provide enterprises with an easier-to-use and faster-to-deploy call center system. But there’s deeper meaning to Amazon Connect than simply a new service from AWS.

From a technology perspective, Amazon Connect works the same way as Amazon’s customer service system, incorporating its Lex AI technology for natural language processing, which is also used by the Alexa virtual assistant—yes, Alexa from the Amazon Echo.

The service lets users to dynamically configure customer interaction processes. Of course, it’s easy to integrate with AWS’s IaaS cloud.

But what’s unique about Amazon Connect is that AWS is moving up the stack. Although storage and compute are AWS’s bread and butter, higher-level services like Amazon Connect are likely to be AWS’s focus going forward.

The reason is simple: Such services are usually more profitable for vendors, and customers historically stay with them far longer than they do with infrastructure services (it’s much easier to change a server than a software system).

AWS won’t be the only one looking to use its cloud to move up the stack. Microsoft already offers a few business services, and I suspect it will buy more this year—ditto for Google.

Both Microsoft and Google started with SaaS, moved to PaaS, then IaaS. AWS seems to be going in the opposite direction.

What should enterprises think about this development? Anything that can solve a problem that you don’t have to build yourself—that’s a good thing. Amazon Connect is an instance of a solution for call centers. Similar solutions are likely to follow from AWS, as well as Microsoft and Google, building upon their existing basic cloud services.

While most will be tempted to call these SaaS, they are really a hybrid of SaaS, PaaS, and IaaS. Connect, for instance, is fully extensible using a configuration approach, but you can also broaden it with the vast number of AWS tools. Thus, these types of cloud services become more valuable, considering that most SaaS providers give you only what they got, and extending their capabilities is not an option for most.

Powered by WPeMatico

IT pros agree: Security is better in the cloud

About 42 percent of IT decision-makers and security managers say they are running security applications in the cloud, according to a survey of about 300 IT security pros from Schneider Electric. Almost half of those surveyed said they are likely or extremely likely to move their security operations to the cloud in a few years.

In the survey, 57 percent of respondents believe the cloud is secure. The cloud has the most confidence in on-demand security, and that confidence is highest among IT professionals (78 percent). I’ve stated before that cloud security is better than on-premises security, but it’s nice to see external evidence backing that up. 

The fact of the matter is that security is a complex and expensive set of technologies. Moreover, security is only as good as its ability to be proactive. Cloud-based security has been able to outperform traditional security approaches and technologies for a few key reasons:

  • The ability to be more proactive: Cloud technology is on-demand, so it can combat emerging and changing threats with updates that occur automatically.
  • The cost: Most on-demand security services charge by use, not for licenses. This means you pay for only what you work with.
  • The ability to better integrate security and devops: Security and devops seem to mix best when security is part of a service accessed outside the development and deployment platforms. That external, service-oriented nature means security can easily be made part of most devops processes.

On the downside, Schneider’s survey suggests there are considerable barriers that still need to be overcome. For example, 54 percent indicated that their security systems aren’t able to adopt new systems and services.

Still, it’s clear that cloud-based security is not only an option, but the preferred approach.

Powered by WPeMatico

In the cloud, you don’t need a college degree

Like most in this business, I have an advanced degree. I even taught computer science at the college level part-time for eight years before life got too busy.

That said, you don’t need a college degree to be successful in cloud computing. In fact, over the last few years, I’ve seen a clear trend toward accepting those without degrees not only in cloud computing specifically but in tech in general.

Although many tech companies and enterprises state they want candidates to have at least a bachelor’s degree, I find that most don’t actually care these days. They see 20 cloud computing jobs chasing one candidate, so it’s a seller’s market.

Employers are looking for people with certifications—for example, with AWS. After that, they seek people with initiative and demonstrated ability. Having a college degree is further down the list.

Cloud computing requires skills—not random skills, but specific skills such as cloud architecture, cloud development, cloud databases, and cloud security, with a further focus on AWS or Azure development or expertise in particular types of cloud database. You wouldn’t pick up those skills in college anyhow.

College is simply no longer a hard requirement for working in technology, including cloud computing. If you get focused training and certifications, you’ll find that you’re accepted more often than your high school counselor would’ve told you.

I’m not saying a college degree, and the loans that come with it, are worthless. It’s where you learn the fundamentals that give you an advantage in learning specific areas on the job, especially in areas that require understanding connections and patterns like architecture and security.

But someone who learned the specifics on the job and in other nonacademic venues can build the necessary level of knowledge, not only specific technical skills. Of course, you need initiative to get there.

My recommendation if you’re going down the noncollege route is to map out a path for your training. This means not only taking certifications from cloud providers, but also some training around less tactical topics such as cloud architecture, security, and monitoring.

Your training path must also include on-the-job training—it is often more important than what you learn from certification and external training. On the job, you must learn to deliver solutions effectively, as well as understand them.

The ability to understand the problem domain and deliver an effective solution is in fact the best metric for success. Because first and foremost, both tech companies and enterprises look for what you’ve accomplished.

Powered by WPeMatico