devopsy.kinsta.cloud

Tag: PaaS

  • The Path to App Modernization: Benefits, Pitfalls and the Route to Success

    The Path to App Modernization: Benefits, Pitfalls and the Route to Success

    There are many reasons an organization may find itself on the path to considering the risky journey of application modernization. It could be to gain an edge or to build a more competitive positioning, or a business could have a legacy system running on infrastructure that is no longer viable, leaving them no other choice. But the conundrum for organizations still resurfaces when considering app modernization; they must select one of these two routes: Either “the failure rate is high, and failure is simply not an option” or “Everyone is still doing it, so let’s forge ahead.”

    The Benefits of Choosing Application Modernization

    Whether an organization chooses this path out of necessity or ambition, modernizing an old IT environment can deliver several benefits, ranging from reducing outdated hardware and software to creating new value through innovation. Specifically, the key benefits are:

    ● Reducing technical debt and improving the underlying infrastructure: Improved security, operations, reliability and scalability.
    ● Decreasing expenses: Lowering the cost spent on expensive hardware and software improves the utilization of resources, thereby decreasing the total cost of ownership of technology operations.
    ● Accelerated time to market: Modernized IT and product development gain value from technological improvements that decrease the time it takes to develop and deploy new products and services.
    ● Agility in the market: Modernization enables an organization to react to changes at an accelerated rate, providing a competitive edge in the market.

    Choosing the Best Path to Application Modernization

    There are different paths to modernization, each with its own focus. On the one hand, there’s the infrastructure aspect of building your platform engineering practice versus adopting a service approach with a platform-as-a-service (PaaS). On the other hand, there is the actual process of modernization with options like refactoring, re-platforming or rewriting your systems, either in-house or through outsourced services. It ultimately starts with modernizing the relationship of the application with its infrastructure and changing some assumptions.

    Once you have a baseline, running everything else should come from a cost-benefit analysis. A scalable, well-managed monolith is valuable despite its age. Ensuring horizontal scalability and a robust backup strategy are key to effectively managing mutable data.

    First, understand the blockers in your current implementation that would complicate a shift to the cloud. Or identify where the result may not deliver any value.

    There are very common anti-patterns that remain anti-patterns, whether on the cloud, running on managed hosting or on-premises. Identifying them allows you to start absorbing technical debt regardless of whether a move to the cloud happens as intended.

    Anti-patterns to look out for are:
    ● Weak separation of code and configuration: You want to be able to run many parallel instances of each application as separate environments. Telltale signs are hard-coded URLs and service credentials. The dependency is the capability of running ephemeral preview environments that are quick to launch and quick to destroy, such that you know that you are “cloud ready.”
    ● Weak separation of the read/write domain from the read-only domain: In a cloud deployment, you want a build step that creates immutable artifacts that are not modifiable in production, and you need to know where all the actual data resides. Older applications tend to “believe” they own the whole disk.
    ● Manual configuration of services: You should be able to run “stock” services without any manual configuration in case the need for a specific database configuration arises and signals the likelihood of an application issue that requires debugging.

    Simply packaging a Docker container or a VM image and deploying to an IaaS won’t create any benefit and only increases costs. The first step to success is a thorough clean-up and update of the documentation to start the process.

    The one basic rule to follow is the ability to run an arbitrary number of instances of every element. Achieving this will allow everything else to flow. There is no need to rush to transform all Crons into “separate workers” and break the monolith into microservices. But the proof that it is possible now exists.

    The Best Approach to Application Modernization: In-House or Outsourced

    A mixed approach between in-house and outsourced is often optimal. There are many elements to consider. If you have a minimal in-house understanding of what the cloud imposes as constraints, you may be tempted to go for the simplistic lift-and-shift approach. Outsourcing everything can lead to huge amounts of lock-in.

    There are ways to cut corners that could simplify and accelerate the initial project, but this could increase the costs down the line. There needs to be a level of abstraction where using a PaaS is a winning proposition and can provide quite a bit of abstraction at no cost.

    Without control, the project may end up as something that “runs on the cloud” without the actual benefits. But there are many ways to do that.

    The Right Mindset Will Help Avoid Pitfalls Along the Way

    By neglecting constraints and skipping the necessary preparation, the costs may escalate. Running big chunks of hardware continuously versus using small ephemeral resources as needed typically leads to significantly increased costs over time. Full rewrites often go wrong when trying to obtain all the benefits immediately.

    A simple four-step approach for success is:

    ● Start with modernizing the relationship of the application with its infrastructure and changing assumptions.
    ● Identify and address the blockers in the current implementation–this makes a shift to the cloud less complicated and enables a smoother transition.
    ● Set a baseline that allows everything else to run from a cost-benefit analysis. Ensure horizontal scalability and implement a robust backup strategy to effectively manage mutable data.

    Accepting that app modernization will be a journey and that the initial implementation is a slightly more scalable and resilient version of the original. This is often a better mindset that leads to a more effective process.

  • Know What You Want and Need

    Know What You Want and Need

    Over the years, what we purchase from vendors has changed significantly. It used to be that IT would define a need, go out and find a bit of software to solve it, install and configure the software and, in most cases, spend the majority of time on the project getting it to work correctly in their environment. Those days are largely gone. First, we started buying appliances for some functionality, then we started using MSPs for some or all functionality, then some vendors wanted to deliver in a VM where they could make configuration much easier by controlling the environment. That was the first step to virtualizing purchases. Then we started looking at infrastructure-as-a-service (IaaS), then SaaS, then some vendors offered PaaS … Currently, all of the cool vendors are offering containers—which are an improvement over VMs, and offer a virtual appliance that is quick to get running and tested to do what it was purchased for. Or at least tested to do what it was sold for. We’ve all got stories about what we did with these purchases that were “off label”—things that a product really wasn’t designed for. Along the way, we also introduced open source vendors; a bit of an oxymoron that really described service orgs that base their product on an open source project. Some far more successfully than others.

    And all of that, dear reader, is why we are here. Before purchasing, there is a lot more to find out than there used to be. What, actually, is the product this software vendor is selling? In the end, IT is looking to solve a problem. Most of the time, whether that problem is solved by SaaS, local install or cloud instance is less important than how well the problem is solved. But implementation—and licensing—are important to an organization if not immediately, then over the long term.

    When purchasing an open source “product”, you’re … actually not. You are getting the product and purchasing support. Since open source can be hacked to run just about anywhere given enough time, more than one OSS vendor has pretended that makes them superior to commercial products targeted at a specific platform. That is blatantly untrue—unless the OSS vendor is supporting the product anywhere and everywhere which, of course, they are not. I can port the OSS project MyFunApp to any platform I want without paying for support that won’t do a thing for me when I get it up and running on OS/2 (as an extreme non-existent example).

    SaaS has more issues when it comes to TCO. While pay-as-you-grow is cool and all, locking in a monthly payment forever is a big step and should be considered. And at an enterprise, “forever” needs to be considered realistically. Implement a particular SaaS CRM and you are unlikely to move to another, even if you claim that you will in a heartbeat. It’s work. A lot of work. It is definitely possible, but for most organizations, unlikely. So know what you are getting into. And while you are evaluating, don’t forget to consider variable charges, which most SaaS products have. Make certain you understand what the actual monthly costs are likely to be. IaaS suffers this same variability problem, as many of us have learned.

    Containers are a very sweet solution to appliance-like functionality—drop a container into your Kubernetes flavor of choice and move along. The problem here is a combination of proliferation—how many are required? One per pod can get expensive over time, for example. Those resources aren’t free, no matter the platform. The other issue is updates. Automatic updates are the norm for container instance-delivered products. From a security perspective, you should have questions. Updating things in your network should probably require your approval.

    I’m not suggesting that one delivery method is better than others here; I’m simply suggesting that we all need to be more deliberate about those choices than we’ve needed to be in the past. Knowing not just SLAs but the cost and support implications of every choice is important both today and down the road.

    Keep kicking it, and keep picking the solutions that best solve the organization’s problems. Just be aware that sometimes, the issues a delivery method introduces undermine the effectiveness of the solution.

  • Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic today at the KubeCon + CloudNativeCon North America conference unveiled a platform-as-a-service (PaaS) environment for building cloud-native applications using Web Assembly.

    Based on the open source wasmCloud distributed computing environment now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), the Cosmonic PaaS gives developers access to a lightweight environment that makes it simpler to quickly build applications that can run anywhere.

    Cosmonic CEO Liam Randall said a PaaS enables developers to achieve that goal by making databases and other non-functional services available via an abstraction layer that eliminates the need for developers to provision these resources themselves.

    Designed to be deployed on any cloud service or on-premises IT environment, the Cosmonic PaaS also enables developers to define their own laptops, cloud resources or entire data center by combing resources to create Constellations. Cosmonic also enables developers to build a Super Constellation by adding customer-hosted components to the services provided by Cosmonic.

    Originally developed under the auspices of the World Wide Web Consortium (W3C) for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The wasmCloud project was created by Cosmonic to provide an open source application runtime that hosts components, written as Wasm modules, that can then be loosely connected to build applications. Cosmonic reports there are now more than 100 members of the wasmCloud community.

    The Cosmonic PaaS extends the capabilities provided by wasmCloud so developers can now more easily build Wasm applications via an abstraction layer defined by Cosmonic. Those applications are also more secure than applications built using previous software artifacts because all Wasm code is executed in a stateless and reactive sandbox that prevents malware from moving from one software component to another.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Every earlier format for building applications locked developers into a specific platform. Wasm is the first software artifact that enables applications to run on any platform, including Linux and Windows, without any modification required.

    Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Obviously, Wasm has major implications for DevOps teams, and Randall said Cosmonic is working toward integrating its PaaS with multiple continuous integration/continuous delivery (CI/CD) platforms.

    It’s not clear how quickly Wasm will drive a transition to another era of computing, but the ramifications for how IT is managed in the next era of cloud-native computing could be profound. It remains to be seen how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that there are an increasing number of platforms that will make it possible to more easily embrace Wasm.

  • Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A South Korean conflagration leads to a ridiculously long outage, and the price of public cloud is skyrocketing. (more…)

  • Solving the Speed Paradox With Open Source PaaS

    Solving the Speed Paradox With Open Source PaaS

    The number of DevOps tools keeps growing, as does the number of cloud resources and options to manage those resources. On EC2 alone, AWS offers nearly 400 instance types across storage, networking and operating systems. Complicating this further is that users can choose from machines located in 24 regions and 77 availability zones.

    This proliferation is driving a ‘speed paradox’ wherein the faster you grow the more fragmented and complex your ecosystem becomes which, in turn, slows everything down. Most DevOps teams struggle to keep up with the demand for more environments from developers.

    The Speed Paradox

    The Rise of the Internal Developer Platform (IDP)

    One intriguing solution to the speed paradox is the internal developer platform (IDP). As its name suggests, an IDP provides a single place where developers can find all the resources needed to run their environments. An IDP allows developers to speed development processes by offering improvements in:

    • Efficiency – Simplifying access to development and testing infrastructure through a self-service experience;
    • Consistency – Providing a consistent way to consume infrastructure resources across teams; and
    • Visibility – Providing a single place to see all the pipelines, workflows and states associated with each environment.

    Gartner sums it nicely: “Product teams often struggle due to disparate tools and disjointed workflows as they accelerate digital transformation. Software engineering leaders leading platform teams must establish internal, self-service developer portals to enable consistency and scale cloud, agile and DevOps initiatives.”

    Lessons From the ‘PaaS-t’

    The idea of a developer platform isn’t new. Previous-generation PaaS—Google App Engine, Heroku Cloud Foundry, for instance—provided a simple interface to write applications by abstracting cloud resources. But early PaaS failed, perhaps mostly due to the long tail of developer needs. Back in 2013, I observed: 

    “Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions and users always want 100% of what they want.”

    You can sum up the failures of early PaaS in three points:

    • Too opinionated: It is hard (impossible?) to control the way the platforms run their infrastructure resources. You’re dependent on the platform vendor for customization.
    • Limited to simple web applications and language choices: Modern SaaS applications are complex and include backend services that don’t fit that architecture.
    • Maturity: Early PaaS attempted to abstract cloud when it was a young, moving target.

    What’s Changed?

    With early PaaS, we traded simplicity for flexibility. Finding the right balance between the two is the heart of the challenge. Kubernetes and Docker, as well as IaC tools like Terraform, Cloud Formation and Azure ARM are a great substrate: They provide a consistent framework to manage applications across a wide range of infrastructure resources among clouds. Maturity and adoption of these tools reduces barriers to build a developer platform. This opens the opportunity to create a custom platform for each organization, allowing teams to control how their platform fits into their organization’s environments. It also offers balance between simplicity and flexibility, because each organization can choose where to draw the line—and even redraw that line without being dependent on an external vendor.

    The next-generation platform 

    Enter Backstage

    Backstage is an open source IDP project led by Spotify. Its three main parts are:

    • Service Definition—Based on the Kubernetes template format, it provides a service descriptor that fits into a range of services: monitoring, CI/CD and Git repositories
    • Backstage service catalog—Basically a web application with a database backend providing a single point of access to manage resources
    • Integrated tooling via plugins —A marketplace of integrated resources

    Here’s how an IDP based on Backstage can look:

    An example of an internal development platform based on backstage

    We can use Backstage to organize all development services and resources such as our squad KPI, the development pipeline, API and Git repositories, all in one place.

    Turning Backstage Into a Full-Blown PaaS

    One of the missing pieces in Backstage is infrastructure provisioning. Adding it turns Backstage into something closer to a full-blown PaaS. Cloudify provides a remote execution engine that integrates with a variety of infrastructure resources and allows users to organize them into a self-service development or production environment. The integration of Cloudify into Backstage includes synchronizing the development environments into the Backstage service catalog and allowing self-provisioning of those services through the Backstage portal or through GitOps.

    Integrating Cloudify as a remote execution engine to Backstage 

    You can watch a demo or get more information on the integration from the Cloudify Backstage Git repo.

    The End of ‘Growth At Any Cost’

    Last year, Sarah Wang and Marti Cassado analyzed the impact of cloud spending on hypergrowth companies. As tech companies trade away efficiency in pursuit of velocity, they face a non-sustainable growth model where cloud costs surpass 50% of total revenue. Wang and Cassado’s analysis illustrates how this condition directly impacts a company’s profitability—and valuation.

    In today’s market upheaval, it’s even easier to see how a “growth at any cost” policy is unsustainable. Today, DevOps teams have to find ways to support growth while controlling costs. This forces organizations to better control how development teams use cloud infrastructure. 

    IDPs can become a major tool in this effort. Unsurprisingly they’re becoming the next hot DevOps trend. Backstage provides a great framework and ecosystem to shorten the time a team needs to build its own internal platform and Cloudify provides the open, remote execution engine with a single place to organize infrastructure resources into a self-service environment. The integration turns Backstage into a full-blown PaaS.

    The current Cloudify-Backstage integration is only an MVP release. Next, we’ll deepen the integration, providing more monitoring within the Backstage portal. Here, you can find more information on our open source contribution to Backstage and offer feedback.

    An Open Source Solution to the Speed Paradox 

    The “speed paradox”—where the faster you grow the more fragmented and complex your ecosystem becomes, which in turn slows everything down—need not grind our DevOps agility goals into the ground. By using open source Cloudify integrated into the Backstage project, DevOps teams can avoid becoming the new bottleneck in software development agility goals. 

     

  • Encore Platform for Running Distributed Apps in the Cloud Arrives

    Encore Platform for Running Distributed Apps in the Cloud Arrives

    Encore has made generally available a namesake backend development engine for rapidly building scalable distributed IT environments across multiple cloud platforms.

    Fresh off raising $3 million in seed funding, Encore CEO André Eriksson said the Encore platform analyzes source code to eliminate the need to manually configure, connect and set up portable cloud computing environments.

    In addition to being able to automatically setup and manage cloud infrastructure based on the metadata surfaced by static analysis tools, Encore provides access to a built-in continuous integration/continuous delivery (CI/CD) platform, previews of environments, live reloads of cloud environments, authentication, secrets management and automatic distributed tracing capabilities.

    Eriksson said the development of the Encore environment was, in part, inspired by how developers of games today routinely use an engine to build application environments rather than presenting developers with a set of text-based editing tools to build those environments using low-level boilerplate code that has to be written by developers for each application instance.

    Written in the Go programming language, Eriksson said Encore platform is based on an open source Encore Go Framework that prevents IT organizations from becoming locked into an Encore platform that today can be deployed on Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud services.

    The building and deploying of distributed applications has always been a major challenge. Encore is designed to automate most of the routine tasks that DevOps teams today need to manually perform for each distributed application they support. As the number of applications being deployed across various cloud computing platforms increases, the challenges associated with managing those environments increase. Encore is designed to enable developers to easily build and deploy application code in a way that can be centrally managed by a DevOps team, noted Eriksson.

    It also takes advantage of the concurrency capabilities that the Go language enables to make it simpler to build and deploy distributed applications in a cloud-agnostic manner, said Eriksson. DevOps teams can also employ Go to extend the Encore environment within the boundary of certain limitations, he added.

    Essentially, Encore is making a case for an opinionated distributed computing environment that, in return for less flexibility, promises to make it simpler to deploy complex applications. Eriksson said Encore doesn’t see many DevOps teams looking to deploy distributed applications that span multiple cloud services, but they are being required to deploy more applications on different cloud platforms. Each cloud platform a DevOps team needs to support only serves to make the overall IT environment that much more complex to manage, he noted.

    It’s not clear to what degree IT organizations are ready to embrace a more opinionated approach to managing cloud computing environments. However, the concept of relying on one is hardly new. Platform-as-a-service (PaaS) environments have been employed for years. However, with the rise of microservices-based applications that are inherently distributed, the issue may soon be forced as IT organizations find simply no other way to keep pace with the rate at which applications are being developed and then continuously extended after they are deployed.

  • Shift Left: Right or Wrong?

    Shift Left: Right or Wrong?

    The term DevOps emerged into mainstream software development communities roughly 10 years ago. It represented a combination of tools and techniques which helped solve many pertinent issues of the time, namely responsibility for code in production and lack of a positive feedback loop. As of today, DevOps is a massive movement. It is considered the default way in which software development should be practiced. It has allowed even small teams to function with the same efficiency as much larger ones. Several engineering teams have adopted derivative approaches of the DevOps methods in order to suit their niche workflows.

    The Dark Side Of DevOps

    DevOps in practice presents a lot of tangible benefits to software engineering teams. Automation, transparency, and velocity are the chief advantages. From a business perspective, engineers are now more invested and accountable for the experience of users. The era of “Your Success Is Our Success” has finally arrived for engineers—and business teams couldn’t be happier. 

    For the individual developer, the number of things they were responsible for was piling up. More objects to monitor in production. As more features were getting built and deployed, alarms from internal systems kept going off more frequently. Individually, an engineer became responsible for the behavior, performance, security, compliance and so many other aspects of the application and underlying systems. Often, this became a distraction and began to defeat the very purpose of the DevOps methodology which meant to remove hurdles that were in the way of developers. 

    This is DevOps done wrong. Lack of maturity within software engineering teams has caused a lot of people to go down a DevOps path that is toxic and consequently forced engineers to burn out quickly. The core tenet of DevOps is to enable engineers to do more, but not to the point where they’re having to undertake enormous toil. DevOps still recognizes two distinct forms of specialized effort – software development and platform operations. The nature of services, scaling, and security may vary the degree to which dev and ops responsibilities converge. 

    Dev-Oops: It Goes Wrong Over Time

    Interestingly, engineering teams view DevOps as development, and “everything else”. From the time a developer checks code into version control, there is a large assortment of workflows that kick in. Ideally, there is testing, integration, more testing, deployment and feedback. This is a large body of work, often underestimated and underrepresented. To pile this responsibility onto members responsible for development alone is where things begin to go wrong. Often, as a product ages, incident management, maintenance, and other engineering efforts pile up–resulting in fewer cycles being available for product development over time. 

    There is also the complementary case, where engineering teams are focused on product development and assign most free cycles to it. Platform operations are forced to become a watered-down effort and consist of the bare minimum it takes to keep the lights on, so to speak. This is a common observation in small teams and startups that typically have a new product release. 

    When implemented correctly, DevOps must allow engineers to take responsibility for all aspects of developing a feature and managing it in production. This means that programming the business logic, creating the declarative and non-declarative software, binding with services, building the artifact, and finally deploying to production all come under the gamut of a developer. In addition, a feedback loop—created by baking observability into the mix will provide insight into the health of the service (or feature)—will require the engineer to stay on top of the operational aspects of performance and reliability. 

    The current definition and practice of DevOps originated from Agile methodologies. They take off from the limitations of typically Agile teams which were released in “sprints”, still kept dev and ops efforts separate, and were agnostic of underlying tech. DevOps, on the other hand, is more tightly-coupled with the technology employed, for example: Microservices and automation. It facilitates continuous deployment and a high frequency of releases. Most importantly, it converges the notions of development and platform operations. We find that the interpretation of this “convergence” is what differentiates good implementations of DevOps from bad ones. 

    The Right Kind of Shift Left

    At the heart of healthy DevOps adoption lies a technology shift complemented by a cultural shift. The fundamental principle that belies successful teams is a great developer experience. Irrespective of the infrastructure that powers the technical stack of a web application, software engineers who work on it need to be able to develop and deploy with ease. Let’s explore how. 

    Examples of tools that aid engineers during the development phase include IDEs, Source Control, TDD suites, documentation generators, and many more. Tremendous amounts of research and product development are currently underway in enabling developers to program better and facilitate more efficient development. 

    Different skill sets and focus areas are required to optimize different portions of the operations spectrum. In the case of large enterprise organizations, the dichotomy is clear. There are Platform Operations teams that are responsible for keeping all the systems running by providing automated means to set up and sustain reliable systems on the server side. Application Development teams are tasked with creating the applications, API endpoints, integrations and various other artifacts that will enable users to execute their tasks. 

    Because of the common underlying nature of both these functions–writing software–they tend to cross-pollinate. This coalescing is welcome, provided it is managed well. This is where abstractions come in handy. In particular, PaaS abstractions that provide in equal parts agility and intransigence. Pliant enough to accommodate custom workflows and bespoke needs of software products and teams, and yet preventing needless osmosis between Dev and Ops responsibilities, ultimately resulting in a superior developer experience as the nucleus of this atomic transformation.

    PaaS With Flying Colors

     

    The PaaS-low’s Hierarchy! 

    The perfect balance can only come from PaaS systems that comprise an architecture that is modular and offers the functionality of application build and deployment. The ability to work across multiple languages and frameworks combined with packaging and deployment best practices is a basic tenet. Abstracting the underlying infrastructure to favor support for container-based artifacts and orchestrating them at scale is the next most desirable component of a PaaS framework. A batteries-included approach to automating continuous delivery, security best practices, and other workflows goes a long way in ensuring that the PaaS substrate works for all kinds of developer needs. When using abstractions, the biggest opacity comes in the form of a lack of production parity. If the PaaS can be functional on all staging instances viz. dev, test, pre-production, prod, or any other remote instances, it would save tremendous toil arising from a lack of parity. 

    Bonus points for being open source and accommodating compliance, policy mandates, and customization to suit the dynamic needs of different organizations. An active community supporting the ecosystem and driving innovation and change management would make a more compelling case for PaaS tools.