PRESENTACION DE RESULTADOS

• Potential for Vendor Lock-in. If your code developers need more flexibility than the current PaaS provider delivers, application portability can become a problem. The application that you build in some of those environments is designed to take advantage of the scalability of that particular platform’s architecture. So you’ve got to balance this consideration against the cost of deployment and potential re-architecting of that application for movement to another cloud provider. For many, vendor lock-in is not a big issue. If you do, however, have a complex application requiring more control you may find yourself needing the flexibility to be able to move that application into a new development environment or language.

• Rapidly Evolving Market. As mentioned earlier in this chapter, the PaaS market is evolving very rapidly and this alone has the potential to make many hesitate before embracing PaaS, which can be a costly mistake. If you are at all curious about PaaS, you really should be building something now before you commit to the service.

• Proprietary Platforms are not Suitable for Deploying Existing Applications. While you can take certain existing web

applications and port them to a platform offering, if you want to deploy an existing application to a PaaS platform, you will most likely need to re-architect. It may be better to look at new applications rather than trying to rewrite old ones.

Cautions and Considerations

What are some of the key cautions and considerations to keep in mind as you plan your PaaS deployment?

1. It’s a Very Dynamic Market! You’ve heard this about IaaS but the same is true for PaaS. Providers are constantly releasing new platform features and the baseline of services available varies significantly among the major players.

2. Trust, but Verify. This market is not only dynamic, it’s hotly contested. Expect to see claims and counterclaims among the providers and in the blogosphere about provider offerings.

Cloud Service Models: Platform as a Service (PaaS) 44

3. Change of Service Provider. As mentioned earlier, you’ve got to plan for portability, especially if you’re investing in a long-term project.

4. Consider a Private Versus a Public PaaS. If you’re a large organization with specific middleware requirements, you might want to consider a private PaaS. This will give you more control over your own code libraries, proprietary data formats, and application frameworks while still getting significant benefits over traditional development models.

5. Need to Accommodate Multiple Development Teams. While a single provider will support standardization and objectives, if you have multiple teams working on projects, a single provider may not meet all the teams’ true requirements.

6. One PaaS Does Not Fit All. Keep in mind that PaaS providers have designed their services to support a specific development language or set of languages. There are many different programming languages and frameworks on which a web application can be built, including but not limited to: Java, PHP, JavaScript, Ruby on Rails, and .NET. Not all PaaS offerings will support all languages and frameworks.

7. Beware Cross-Cloud Latency. In the event that you need to span across different PaaS environments to build your application, inter- cloud latency can become a real issue. Be sure you test

performance and latency of the distributed application thoroughly.

8. Crunch the Numbers. PaaS fees can be rather confusing, so pay special attention to how charges will be incurred. Fees can vary from monthly or daily subscriptions to metered billing based on actual resource consumption (like storage, bandwidth in and out, and CPU usage.) Often you’ll run into pricing models that combine subscriptions with metered fees.

9. Read the Fine Print. Again, something we stress in every chapter of this book. It’s very important to look at and understand the fine print in the SLA and ToS before putting anything into production. Be sure to verify what the cloud provider is going to provide, what they’re going to be responsible for, and what their availability is going to be.

You’ll also need to confirm how to get your data into the cloud, as well as how to get it out of the cloud in the event that you want to move on to some other platform.

Cloud Service Models: Platform as a Service (PaaS) 45

46

Now we come to the elephant in the room – cloud security.

Because many of the features that make cloud computing attractive can also be at odds with traditional security models and controls, cloud security is a particular concern for the federal government.

In fact, according to the Cloud Security Alliance, 70 percent of government technology decision-makers are concerned about data security, privacy and integrity in the cloud.

Driven by the imperative of the Cloud First mandate, cloud security is such a hot topic for the federal government that NIST expedited the development of federal cloud security guidelines that advise agencies to consider security as a priority issue before they deploy any form of production environment in the cloud. Yet questions and confusion remain about the critical aspects of cloud security and their impact on long-term cloud strategies. For example:

• What are the key security and privacy concerns and issues that cloud computing has brought about and how can you tackle them?

• How can you identify a cloud model that meets your agency’s needs?

• What do you need to know about your cloud provider before you trust them with your data?

This chapter will address these questions and suggest some tried-and-tested strategies for securing public cloud resources.

Learn about:

— Current Data Center Models: It’s All Inside

— The Public Cloud – Who is Responsible for What?

— Cloud Threats and How to Combat Them

— Balance Security Controls with Acceptable Risk

Chapter 5