Cloud development and cloud-native development, both refer to building a software application designed to run in a cloud computing environment within and specifically for that environment.
In a traditional software development approach, software is developed and tested on a computer and then run on either physical servers or a private or cloud as a production or ‘live’ environment. In cloud development, the software is developed, tested and run within a cloud environment.
In this blog we’ll:
DevOps teams and consultants
Supercharge your next cloud development project!
Cloud development or in-cloud development are two different ways to say the same thing. The latter is less common but removes any ambiguity between developing software for the cloud and developing a cloud infrastructure, which is of course a very different thing.
Whatever the preferred terminology, the core point is that if an app is intended to be run in a cloud environment, it is generally far more efficient to also develop and test it in the same cloud environment.
Over the past couple of years there have been a number of developments leading to the belated mainstreaming of cloud development, which has been around for almost 10 years without, until recently, establishing itself as the software development standard:
The above are ‘macro’ trends that have evolved over recent years in a way that has encouraged increasing adoption of cloud development and cloud native development as a standard. The following are the inherent advantages of cloud development that have these trends have played in to:
The evolution of cloud computing has also catalysed a parallel evolution in software architecture – the progressive disaggregation of applications into smaller components, or building blocks. The inherent qualities of mainframe servers were naturally compatible with monolithic application designs and architectures, where the entirety of an application’s coding was packaged and run as a single unit.
Distributed client-server systems and browser-based web applications started the process of apps being broken down in modular architectures that split functionalities across elements. Cloud platforms like AWS that originally only offered data storage and computational power started to introduce what has become a broad ecosystem of services, from managed database and analytics services, to container runtime environment and serverless functions.
The fact that a cloud environment escapes the complexities added by differences in hardware and operating systems makes this standardisation possible.
At the same time, code frameworks and libraries, such as the popular JavaScript examples of Angular and React, gained traction. Code frameworks and libraries also standardise chunks or modules of code for common user-facing functionalities.
The result has been increasing granularisation of applications on both the front and back-end. And these small blocks have been standardised, much like Lego or Meccano. Granular enough to allow for them to be put together in a myriad of different ways to achieve the desired end result.
Standardisation in software development, and the option to give colleagues direct access to a cloud environment where work is being done, means team members can share their work and support each other far more efficiently.
This quality of cloud development has led to new and improved forms of collaboration between not only development teams. It has gone a long way towards paving the way for DevOps – the unification of development, testing and operations as a single team with the same end goal – reliable, highly available and high-quality software that delivers for the end user. And ultimately the sponsor organisation by reducing development and running costs.
Cloud, and especially cloud-native development, helps foster a DevOps approach to software development. Developing in the cloud, for the cloud means that a similar environment will be used across the lifecycle of an application, from development and integration to testing, deployment and production. This helps reduce the number of bugs and other issues that can reveal themselves in production, and fosters a DevOps culture.
Cloud and cloud-native development don’t necessitate a DevOps approach. And not every DevOps organisation or software development teams that work to less formalised DevOps methodologies and principles only build cloud-first software. But cloud development and DevOps processes are a natural alliance.
Sticking to DevOps principles and methodologies is made easier by the standardisation of cloud services and unification of development, testing and operations environments. And, likewise, cloud-native development benefits from standardised, repeatable and automated DevOps processes that shorten deployment cycles as part of a CI/CD pipeline.
K&C - Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?
Drop us a line to discuss your needs or next project
The CI/CD (Continuous Integration/Continuous Delivery) pipelines enabled by cloud development and DevOps also naturally tie into the Agile methodology of software development. Building and releasing software in small iterations of functionality, Sprints in Agile terminology, demonstrably reduces costs. It does so by going a long way to helping avoid time and money being wasted developing unnecessary or inefficient functionalities. Or creating a finished product missing functionalities or other features that turn out to be necessary and are more complicated to add in retrospectively.
Cloud-based CI/CD also allows for and inherently means test automation, which Google’s State of DevOps 2019 report finds has a significant impact on CD (cost of development).
The report also perfectly summarises cloud-based development’s impact on application running costs by:
“Why can teams on the cloud better estimate and manage their costs? It is likely because the cloud provides better visibility into infrastructure usage and spend to developers and IT operations professionals. This increased visibility and awareness make it possible to change the way we architect and build our systems while also aligning incentives”.
“While this variability can be initially confusing and overwhelming for those unused to this new financial model, teams can reap the benefits of efficient design by only paying for the compute resources they use”.
“In contrast, the data center in traditional environments is often a ‘black box,’ where information about processing and cycle cost is difficult or impossible to get. Additionally, the nature of capital expenses means that once infrastructure is purchased, there are no benefits for being aggressively efficient with design”.
“In this regard, the capital expenses are a fixed cost—predictable and understood up-front, but rarely visible to the engineering team and impossible to avoid even if more efficient designs are deployed”.
Finally, the combination of cloud development’s qualities of a unified environment between dev, testing and ops, promotion of DevOps practises and better collaboration conditions through ‘anywhere access’ and standardisation means applications fail less often. And when they do, they are generally recovered much more quickly.
Source: Compaid
Cloud development or cloud-based development and cloud-native development are often used interchangeably. There is, however, key distinctions between the two. Cloud development simply means writing code in the cloud, or on a local machine directly connected to the cloud environment, to where it is transferred for testing.
Cloud development requires only a browser or online interface that is connected to a cloud-based infrastructure.
Cloud-native development is a specific type of cloud development that more references what, rather than how, software is developed. The term originates from the Kubernetes and Cloud Native Computing Foundation (CNCF) communities and defines cloud-native development as contain-based, dynamically orchestrated software development that uses a microservices-based architecture. There is an argument that ‘container-native development’, is a better, less ambiguous term than cloud-native.
Cloud-native application architecture, which is based on dynamically orchestrated containers, mirrors the qualities of elastic scalability and high availability of cloud infrastructures. Standard cloud development architectures don’t use containers and rely on the cloud-infrastructure itself for scalability and high availability.
Rackspace summarises the difference between traditional and cloud native application development as:
In summary, cloud development primarily treats the managed cloud environment as a direct replacement for the on-premise server. It cuts down on the upfront investment involved in establishing on-premise server capacity. And allows for scalability in computational power and data storage capacity, which reduces the risk of outages at peak times of demand. However, the underlying app architecture is largely the same as it would be in the case of a traditional app.
Cloud-native development makes full use of the cloud environment by leveraging cloud services and functions within the app’s architecture, and unifying development, testing and deployment environments, allowing for CI/CD pipelines.
For an application to be considered ‘cloud native’, its architecture and development process will feature a majority of the following elements:
Let’s take a look at each of these elements in some more detail:
The virtual containers of cloud native development hold the services that the application needs to run, such as load balancing and networking. The crux of containerisation is that it makes an application portable and mean it can run on any cloud environment with minimal integration work.
Major cloud platform providers like AWS, Microsoft Azure and Google Cloud Platform all offer container management services, which free up engineering resources. Containers can also be managed using commodity services in a DIY approach for greater flexibility. How much of an app’s infrastructure is controlled by its owners, and how much is delegated to a cloud provider is usually a trade-off between convenience, control and cost.
The advantage of traditional, monolithic, app development is that it is initially easier to develop, manage and deploy. The issue is that because all functions are built as a single, inter-connected entity, there are multiple interdependencies that mean updating one can impact on the others. That can lead to failures or avoiding them involving a lot of work.
By contrast, in a microservices approach, each functionality of an application is held within its own container as a stand-alone service. They are connected together by APIs as a functioning app.
The advantage of microservices is that new features and functionality can be built and added to an application far more quickly, easily and with minimised risk of impacting how existing features function. An initially higher investment then realises a return when an application is modified or extended far more conveniently.
In the contemporary environment of agile development, where apps are released as quickly as possible and then modified and extended as functionalities and features are given proof-of-concept in a real-world environment, microservices have come into their own. It is relatively rare that an app will be released without the anticipation of it being updated and extended.
‘Serverless’, means the cloud provider, rather than the operations team of the application’s owner, runs the server and manages the allocation of machine resources on an ‘as required’ basis. The ‘…less’, refers to that shifting of responsibility, rather than the existence of a server.
In a serverless cloud computing execution model, the large part of operations management is outsourced to the cloud platform, which allows DevOps teams to focus on the code itself, rather than its run-time environment. This improves development pipeline efficiency and security. It also brings costs down by minimising the time and specialist know-how involved in keeping an application running on server resources managed inhouse. Cost efficiencies and scalability are also realised from server resource pricing based on what is actually used.
The continuous integration and continuous delivery (CI/CD) practises that are a central pillar to cloud native development help towards better quality applications and faster, stabler updates.
A CI/CD pipeline uses cloud native tools and services such as Jenkins to automate DevOps workflow by starting to test as soon as any code is modified or added to the app. Modifications and new code blocks are also automatically deployed to the production environment once testing is complete.
The end result is, as the name of CI/CD practises would suggest, a ‘continuous’ flow of new updates and features. As opposed to new versions of an application being released every few months, or at even longer intervals.
The key partnership between cloud native development and a DevOps approach to developing and running applications has already been discussed in some detail. But in summary, DevOps is best described as an organisational cultural change that encompasses work environment and a set of practises, supported by tools, that allow development and operations teams to work together as a single entity with one goal – high quality, high availability and secure software delivered and updated more quickly.
We’ve already covered the benefits of cloud, or in-cloud, development. The automation inherent in cloud native development adds an additional layer of benefits:
Freed from server limitations, time dedicated to managing infrastructure, the introduction of CI/CD pipelines and self-healing, auto-scaling applications, cloud native developers are left with more time to focus on the code itself.
The history of humanity, from the introduction of managed agriculture creating a food surplus to more recent developments such as the combustion engine, electricity and finally digital services and products, shows that freeing up time in one area leads to new innovation in others as it is reallocated.
The efficiencies of cloud native development are no exception. They will allow your team to use the time once spent managing server resources and manual testing and deployment, to focus on improving existing products and better, more innovative new creations.
The business agility and momentum that is the result of being able to deploy releases daily, rather than monthly or at even longer intervals, means new products and services can be brough to market faster. And then quickly improved upon. In today’s digital environment, that agility can be the difference between success of failure.
Automated scaling based on the consumption of infrastructure resources allows organisations to create new products and services in a way that optimises both cost and performance.
DevOps practises and automations allow for new ways to improve outdated manual processes across an organisation. This increased efficiency will help improve both employee and customer satisfaction by leading to higher quality products, updated and released quickly and frequently, with minimum friction.
Cloud native development, managed and implemented correctly, can, as we’ve seen, lead to major gains at both an organisational and product level. But any change of processes and technologies ingrained in an organisation’s status quo comes with challenges.
If you would like to develop your next application as cloud native, what are some of the main challenges you should acknowledge and prepare to manage?
The introduction of DevOps processes, whether as a full transformation towards becoming a DevOps organisation, or less formally, will inevitably involve some significant changes in team structures and roles. Those changes are not only surface-level but involve a new cultural approach of shared responsibility and common goals.
Introducing any kind of significant cultural change within an organisation needs to be well managed if negative friction and more teething problems than necessary are to be avoided.
If your existing development and operations teams have not previously built cloud native applications, the chances are they will need training or additional help to plug a skills gap.
You’ll need a DevOps/cloud native architect to plan your cloud native application, someone(s) responsible for making sure DevOps practises are being followed and skills and experience with cloud native/DevOps technologies such Kubernetes, Docker, Jenkins etc. your inhouse team may not currently have.
Organisations moving to a DevOps/cloud native approach to development often have legacy applications and systems that are intertwined with infrastructure. If these applications and systems are business critical, and they almost certainly will be, they will either have to be maintained as they are, or migrated to the cloud.
Migration of legacy applications and systems to a truly cloud native footing can be complicated. But if they have a long-term future, it may be necessary. Ultimately, a decision will need to be made on what legacy systems and applications should be future-proofed through migration to a cloud native / DevOps architecture. And which should be maintained in their legacy form until the end of their lifecycle.
In cloud native development, much of the heavy lifting around application security is handed over to the cloud platform provider. But that doesn’t mean security is no longer a risk and processes do not have to be well developed. Cloud native comes with different security issues that processes will have to take into consideration.
If your cloud native application involves working with particularly sensitive data, especially data that must meet compliance regulations, you may need a multi or hybrid cloud infrastructure that splits workloads between public and private clouds, or even includes a physical server.
How these, and other, challenges are managed will go a long way to determining how smooth a transition to a cloud native/DevOps development model will be, and how much of the organisational benefit is quickly felt.
That cloud native development is the future (and increasingly the present) standard for a majority of new software projects and legacy migrations, is in little doubt. The benefits that both cloud infrastructure and DevOps/cloud native development processes and automation bring to the party are clear.
The question that remains for organisations is how to best manage the cultural and skills transition to a DevOps culture and cloud native development.
K&C’s DevOps and cloud native consultants, architects and software engineers can help support you in managing and bridging the transition to a future-proofed organisation or business.
Let us know how we can help. We’d love to. Get in touch!
When does IT Outsourcing work?
(And when doesn’t it?)