Cloud Computing fundamentals for Developers
Cloud Computing is changing the way developers build applications. Gone are the days of waiting for hardware to be provisioned and the time required to configure it. Developers in the cloud can take advantage of the speed and convenience the cloud offers. However, it does not just happen without gaining the proper knowledge. Let's look at some of the areas that cloud developers need to consider.
Using tools such as the open source tool Tsung, developers can find where performance bottlenecks occur in the deployment of their application.
Best of all, it can be done before ever running the application in a production environment.
Bottlenecks, whether CPU, memory, disk operations, or other, can be fixed in cloud environments by moving to a new cloud server, something that can be done in minutes vs. days or weeks in a traditional data center environment where people and time need to be allocated once the necessary compute resources have been acquired.
For consumer applications, a developer must think about the end-user performance, not just the server processing performance.
Web applications that use client-side rendering frameworks can be optimized using a CDN.
Security in the cloud is a shared responsibility.
While physical access to a cloud environment is controlled by a vendor, developers are responsible for ensuring that applications are granted only the necessary permissions in order to execute. An application has multiple options for interacting with managed services.
Credentials and/or an API key should be properly encrypted at rest and secure communications ensured when in transit. A better practice could be to run the application under a certain user or role that is granted with the necessary permissions since that information is not stored by the application. The approach is a decision typically made by a development team.
Limiting permissions for an application is something every developer needs to understand.
Who else knows the application better than the individuals who wrote it?
It makes the most sense for them to document the access by scripting of policies.
Depending on the organizational structure, those policies can then be reviewed by security administrators before being deployed. In the event of an objection to the policy, a developer with a rich understanding permissions will be able to explain its purpose or propose an alternative solution.
Some managed services provide built-in encryption.
While appealing with its simplicity, developers have to determine if the vendor-provided encryption meets their requirements or not.
How encryption is implemented also depends on what information is to be encrypted. For example, a developer could choose to store passwords in a table of a database. Encrypting passwords would need to be implemented before they are written to the table.
Additionally, the database file might be encrypted by the database engine without being able to override it. In all situations, any developer responsible for designing a system must be aware of his or her options and limitations based on the services used.
In traditional datacenter environments, developers often have to work with system administrators to configure, purchase, and test applications for high availability scenarios.
Companies with budget constraints might forego a production-like development environment meaning a true test of an application's fault tolerance is not possible.
Budget constraints can also affect how applications are designed by restricting the types of technology used. For example, a company could decide against a particular database that has a great new feature that eases development because the cost of implementing a redundant architecture is too much for the company to bear. All of this changes significantly with the cloud.
In the cloud, resources are less expensive and easily replicable.
The cost to run that same database across multiple data centers is lower, and in many cases, already built into the cloud environment by default.
This is not limited to just databases. Web servers can easily be placed behind load balancers that serve traffic to multiple data centers. As a result, developers must understand how to develop applications that can handle normal use (e.g. session state) and potential failure in the cloud. Thankfully, the necessary components to build application environments are scriptable in most cloud environments meaning developers can create, drop, and recreate sandboxes for validating applications.
Consuming SaaS applications leads to another set of skills and considerations for an aspiring cloud developer.
There are many services and microservices that can eliminate the need to implement custom solutions via an application programming interface (API).
When consuming an API, consideration must be made for what happens when the API or network connectivity is unavailable. Staying up-to-date on new versions that can break existing applications is essential. Any developer writing a SaaS API has to consider how to handle requests and responses from consuming applications that may no longer be available.
Deploying an application in a datacenter versus the cloud is not all that different from a development team's perspective.
Many of the tools used for distributing applications across servers are independent of the actual environment.
Examples of those tools include Chef and Puppet. Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) vendors may have their own deployment tools to choose from.
Infrastructure changes required by the application in cloud environments can be scripted to add, update, and remove, making deployments easier to predict and repeatable.
This is something not possible in a traditional datacenter environment.
Developers must now understand a vendor-specific format to make these changes a reality. At this point, they begin to resemble the role of DevOps especially in smaller companies.
Cloud vendors typically have an ecosystem to entice developers with simple, convenient services that nicely integrate with existing services.
This can be both a blessing and a curse.
The blessing comes from the fact that services in the ecosystem are often managed meaning little to no administration is necessary. Managed services are usually less expensive than rolling out a custom solution whether that is in the cloud or a traditional environment.
Developers gain the convenience of not having to wait long to provision resources necessary for development. They benefit from prior experience interacting with the vendor's other managed services.
The curse of buying into the ecosystem is the vendor lock-in.
Over time, the risk of creating an architecture that is highly coupled with a vendor increases.
The application becomes reliant on continued vendor support for the services being used. If the vendor decides to discontinue a service, the business must scramble to find an alternative or build a custom solution.
Applications can be designed to allow for swapping out components. This simple step can help reduce the risk of vendor dependency while permitting the application to take advantage of multiple vendors.
At Cloud Academy, we have created learning paths to help aspiring developers position themselves for great opportunities in an application development career.
As more and more companies adopt cloud environments, the demand for quality developers will increase. Start your learning path today.