Software Engineering and being Agile
Software development and package creation is now an endless cycle of innovation and enhancements. In that regard best of breed practices need to take into account these pressures and trends.
Figure. Notional application delivery cycle—traditional and with continuous delivery
This figure represents a comparison of traditional application development compared to cloud-based development. Technically, this new pace and style of application development is not specific to the cloud; however, the cloud does provide unique capabilities such as elasticity, software-defined networking, on- demand Development/Testing as a Service (Dev/Test), shared application lifecycle platforms and tools, and an enormous worldwide hybrid infrastructure.
Application Categories
Applications can be categorized in many ways, however there are usually four categories which are applicable to a cloud service environment:
Standard COTS or Customized Off The Shelf Apps
COTS applications are readily available from numerous software vendors, but their suitability for implementation in the cloud is not always straight- forward. Many software vendors are rewriting their applications to both fit into a multitenant cloud environment and adapt their licensing models for pay-as-you-go cloud usage models; however, there are still software vendors that do not have properly designed cloud-native applications that work in a multitenant environment.
Open source
These applications are often not shrink-wrapped or ready for purchase such as with COTS products. As the name indicates, open source also means that the source programmed code is freely published so any party can customize it for its own needs, scan it for security vulnerability, and integrate other software components. Open source applications are often considered a community project with numerous (meaning hundreds or thousands) of developers, contributors, and integrators across the world.
Open source applications are free for anyone to download and use, but they sometimes have licensing limitations such as not being able to use them for profit without permission or royalties paid. Some software companies take an open source application, enhance it with their own software, and sell their own distribution of the system. Sometimes open source applications often utilize industry standards and APIs or end up becoming a standard after sufficient adoption and industry acceptance. There are however some risks, including performance, stability, resource support and security.
Custom applications
Also known as home-grown applications, these are what many large organizations have the most difficulty with when planning the transition to the cloud. These applications can range from legacy mainframe programs, all the way to heavily modified COTS systems. Because there are often no integration standards and often little integration among these custom applications, there is also no single method of integrating or porting them to the cloud. Careful assessment and planning for each major application is required. A significant portion of this chapter is dedicated to this assessment topic.
Cloud native
These apps are rarer than COTS or Customized apps. Cloud native applications are designed to be hosted in a cloud environment and take advantage of a cloud infrastructure. This means the applications can, for example, remain online during planned or unplanned infrastructure outages and scale up or scale down to meet workload demands. Cloud applications are designed to work with other components and services within a cloud, such as databases, frontend web services, transaction queuing, payment engines, and so on, all working together in what appears to be a single cloud application or service.
Cloud native apps consist of composable services [SOA component premised software] designed to be dynamic with respect to the infrastructure and other services with which they integrate, essentially discovering and dynamically registering services with other applications and components within the cloud rather than hard- coded mappings or static configuration. Cloud-native applications are developed to be elastic so that they can scale out automatically based on defined workload parameters.
Finally, cloud applications are designed to be resilient so that the system can recover or self-heal when a problem is detected in the infrastructure, such as temporary hardware, software, or communications failures.
Application Characteristics
There are numerous characteristics that an application should have when transitioning to a cloud infrastructure. A public cloud provider will design these attributes into their application and cloud offerings, whereas a private cloud operator will have to assess and migrate legacy applications. Key characteristics of cloud-enabled (cloud-native) applications include the following:
Secure multitenancy
This means that the application is configurable so that multiple customers can share the same instance of it, while maintaining separation of all data and user accounts. Customers and users within the shared application instance cannot see one another nor any data other than their own by using security access controls lists (ACLs), role-based permissions, and some- times separation of databases (the application is still shared but can access and utilize separate databases when appropriate).
Elasticity
Applications should be elastic as traffic, demand, and usage increases. Elastic means that an application can scale out (adding more compute resources or additional virtual machines) to handle an increase in workload or utilization. A properly designed cloud-native application should be able to automatically detect high utilization and trigger the necessary steps to start up new VMs or application services to handle peak workloads. Then, when peak utilization diminishes, it should reduce VMs or compute instances.
Legacy applications that were not specifically designed to run in the cloud can often use a VM hypervisor to monitor processor and memory utilization, triggering more VM instances when a manually defined peak- utilization threshold is attained. These elasticity techniques make it possible for the applications to take advantage of the power of the cloud infrastructure to dynamically scale, even if the application wasn’t originally designed as cloud-native; although, a cloud native application is more efficient.
Resiliency
Resiliency refers to the application’s ability to survive and remain online during an infrastructure outage or failure. A properly designed cloud-native application would have multiple techniques to retry failed transactions and there would be multiple instances of the application services running on other servers or VMs. Legacy applications that were not designed for a cloud can use tools within a hypervisor or cloud infrastructure such as traffic load balancing, clustering, and server/VM failover, but these are not as effective and transparent to the end user as a cloud-native application’s resiliency. There are many other aspects of resiliency and cloud-native application design benefits that will be covered later in this chapter.
Authentication systems
Applications that might have run within existing enterprise datacenters often utilized the internal corporate Microsoft Active Directory or some other identity management system to authenticate user logons. Ideally, applications hosted in a cloud should not assume Active Directory or the internal identity system is available; instead, they should favor an industry standard for authentication and directories such as LDAP or SAML. Both provide authentication capabilities and SAML is a bit more robust and appropriate as part of a single sign-on (SSO) system.
Universal access
The applications must be accessible from anywhere on the Internet or other wide area network (WAN) circuit. The application should be compatible with any and all access methods, from web-based access, virtual private network (VPN) access, and every variety of desktop, notebook, tablet, and mobile device. This also means that the user data must also be immediately available when moving from one computing device to another. As a general rule, you should follow the same philosophy as software-defined networking: never hardcode any network addresses or assume anything; always assume applications, users, and data could exist or operate from anywhere in the world through any network connection and any form of user inter- face or device.
Multi-tiered apps and platforms
Many cloud applications employ a multi-tiered design wherein there are multiple layers, or tiers, of services. These tiers separate the backend data- base, middleware and applications, and frontend processing. This tiered design facilitates higher levels of security, application upgrade modularity, and independent scalability of individual tiers as needed, based on utilization. Tiered applications also benefit from shared platform or PaaS applications in the cloud, such as a database service, that multiple applications can share for lower cost of maintenance, licensing, and operations.
Mobility
With the increasing number of applications hosted in a cloud environment, users or consumers often use mobile computing devices such as tablets or smartphones. The legacy assumption that end users only have desktop PCs or a particular PC operating system (OS) is no longer true. The concept of mobile first was adopted over the past few years but is more recently replaced with ubiquitous access—the intention of both being that applications need to be designed with the ability for users to access the system through any form of computer device, from any location, and have the same experience. Mobility might also require additional security and asset configuration management features and tools to ensure identity, data encryption, data privacy, and synchronization to mobile devices for offline viewing.
The New Approach to Application Development and Delivery
Today’s newest and most modern approach to application development is focused on rapid and continuous delivery usually called an ‘Agile’ approach, and sometimes referred to as ‘Devops’, where the traditional lines between architect, developer and operations engineer, are compressed into one role, with one life cycle management, done by the person who architected and built the code in question. Combining roles has some advantages but also disadvantages. It is recommended that clearly defined roles are still performed by people with those skills. Architecting, networking, app development and testing for example, need to be separated.
Figure Cloud-based application development