PaaS cloud providers enable your company’s developers to create custom applica-tions on a variety of popular development platforms, such as Java, PHP, and Python and Go. Your choice of language and development framework will determine the PaaS vendor you select. Using a PaaS provider means that developers don’t have to manually build and manage the infrastructure components required for each work-load; instead, the required infrastructure resources for each workload running in the development, testing, and production environments are created, hosted, and man-aged by the PaaS cloud provider. After an application has been developed and tested and is ready for production, end users can access the application using the applica-tion’s public URL. In the background, the PaaS cloud provider hosts and scales the hosted SaaS workload based on demand. As the number of users using the workload changes, the infrastructure resources scale out or in as required. PaaS environments are installed on the IaaS resources of the PaaS cloud provider, as shown in Figure 1-8. In fact, IaaS is always behind all “as a service” monikers. Examples of PaaS providers include Google Cloud, Cloud Foundry, and Heroku.
The Cloud Foundry PaaS solution is offered for application development at IBM Cloud, running a customized version of the Cloud Foundry platform components. Developers can sign up and focus on writing applications. All application requests are handled by the PaaS layer interfacing with the IaaS layer, where the application’s compute, storage, load-balancing, and scaling services operate. Another popular solution for developing applications in the public cloud, Heroku, a container-based PaaS environment, enables developers to create and run applica-tions using a variety of development platforms. Just as with IBM Cloud, once the workload is deployed into production, Heroku hosts, load-balances, and auto-scales each workload as required and sends each customer a bill for the infrastructure host-ing costs used each month.
When developing applications at a PaaS provider, remember that programming languages change from time to time; therefore, the associated APIs offered by each cloud provider can change as well—and sometimes without much warning. Devel-opers and companies must keep up to date with any ongoing changes or there can be issues when using a cloud-hosted PaaS development platform.
An additional reality is that one cloud provider’s PaaS offering is not necessarily compatible with another cloud provider’s PaaS offering. For example, Heroku and Microsoft Azure offer similar PaaS cloud services for developing applications, but internally, each cloud provider operates in a completely different fashion, with a completely different set of supporting APIs. There is no single standard for defining what PaaS must be. Compatibility issues can begin to reveal themselves at the lower levels of each vendor’s proposed solution. RESTful interfaces, manifest file formats, framework configurations, external APIs, and component integration are not neces-sarily compatible across all cloud vendors.
AWS Elastic Beanstalk is Amazon’s cloud service for deploying web applications. The service supports Java, . NET, PHP, Node. js, Python, Ruby, and Go. Code applications can be hosted on Apache, Nginx, Passenger, or IIS web servers, and containerized applications hosted on Docker.
Elastic Beanstalk acts as a managed service that frees customers from having to build out infrastructure configurations. It automatically handles scaling, load balancing, monitoring, capacity provisioning, and application updates. For additional details on AWS Elastic Beanstalk, see Chapter 6, “Designing Resilient Architecture. ” AWS has also recently purchased Cloud9, an AWS-hosted integrated development environ-ment (IDE) that supports more than 40 programming languages. AWS has several cloud services to assist in developing applications, shown in Figure 1-9, including AWS CodeBuild, AWS CodeCommit, AWS Cloud9, and AWS CodeDeploy, that can be key components in your application deployment workflow at AWS.
Figure 1-9 Platform Options at AWS
Operational Benefits of AWS
Operating in the public AWS cloud has certain benefits provided by the previously discussed NIST five essential characteristics. Unlimited access to the many cloud services available at AWS may make it easier than expected to operate and manage workloads in the AWS cloud. Consider the following:
- Servers: Underutilized servers in your data center are expensive to run and maintain. Moving applications to the public cloud can reduce the size of your on-premises data center. When you no longer host as many physical servers, your total hosting costs (racking, powering, heating, and cooling) could be lower as well. You also don’t have to pay for software licenses at the processer level because you’re not responsible for running hypervisor services; that’s now Amazon’s job. You might think that moving to the AWS cloud means virtual-ized resources and only virtualization. However, with AWS, you can get an ever-increasing variety of EC2 instances, including dedicated virtual servers or bare-metal servers. Sizes range from a single-core CPU with 512 MB of RAM to hundreds of CPU cores and terabytes of RAM.
- Storage: Using cloud storage has huge benefits, including having unlimited amounts of storage. Amazon has shareable file solutions for both Linux and Windows Server workloads. Virtual hard disks are available using Amazon EBS to create the required volumes. Unlimited storage and long-term archive stor-age are provided by Amazon S3 buckets and S3 Glacier archive storage.
- Managed cloud services: The AWS-managed cloud services, outlined in Table 1-1, may be able to replace or complement existing services and utilities currently used on premises after moving to the AWS cloud.
Cloud Provider Responsibilities
AWS has published service-level agreements (SLAs) for most AWS cloud services. Each separate SLA lists the desired operational level that AWS will endeavor to meet or exceed. Current details on the SLAs offered by AWS can be viewed at https://aws. amazon. com/legal/service-level-agreements. AWS defines its commit-ments in each SLA about security, compliance, and overall operations. The challenge is to live up to these agreements when all services fail from time to time. Each cloud service SLA contains details about the acceptable outage times and the responsibility of the cloud provider when outages occur. Each SLA also contains statements about their level of responsibility for events outside the cloud provider’s control. SLAs commonly use terms such as “best effort” and “commercially reasonable effort. ”
AWS is responsible for overall service operation and deployment, service orchestra-tion and overall management of their cloud services, the security of the cloud com-ponents, and maintenance of each customer’s privacy. A managed services SLA also spells out how a cloud consumer is to carry out business with the cloud provider.
Each cloud consumer must fully understand what each cloud service offered provides—that is, exactly what the cloud service will, and will not, do.
Is it acceptable to expect AWS failures from time to time? It is a reality; everything does fail from time to time.
What happens when a key service or component of your workload hosted in the AWS cloud fails? Does a disaster occur, or is the failure manageable? When operat-ing at AWS, customers must design each hosted workload to be able to continue operating as required when cloud services, or compute and storage failures occur. Designing high availability and failover for hosted workloads running at AWS is one of the key concepts of many of the questions on the AWS Certified Solutions Archi-tect – Associate (SAA-C03) exam. Many questions will be based on the concepts of designing with a high availability, failover, and durability mindset. Customers must design workloads to meet the application requirements, considering that cloud services do fail from time to time.
All public cloud providers really have the same SLA summarized in nine short words when failures happen: “We are sorry; we will give you a credit. ” Here’s another real-ity check: If your application is down, you might have to prove that it was actually down by providing network traces and appropriate documentation that leaves no doubt that it was down because of an AWS cloud issue.
Here’s another further detail to be aware of: If you don’t build redundancy into your workload design, don’t bother asking for a credit. Application designs that have a single EC2 instance hosting a workload with no failover or high-availability design parameters have no cloud provider SLA protection. AWS expects customers to be serious about their application design. Each customer needs to carefully design, deploy, and maintain each hosted workload based on the business needs and require-ments, ensuring that any high availability and failover requirements have been met.