devopsy.kinsta.cloud

Tag: cloud-native applications

  • How to Prevent Zombie APIs

    How to Prevent Zombie APIs

    There is a growing reliance on web APIs. A full 92% of organizations plan to increase their investments into APIs over the next year, the 2023 Postman State of the API Report found. APIs are powering everything from internal microservices strategies to partner strategies and fully-fledged products.

    Yet, this newfound API sprawl has consequences; a looming threat that might rise from the grave to haunt you …

    I’m talking, of course, about zombie APIs. Zombie APIs are endpoints that are no longer maintained yet are still active. They may be unused endpoints, old features never officially deprecated or forgotten development or testing environments. Regardless, zombie APIs are a type of technical debt that could pose a legitimate threat if left to rot.

    The sudden growth of APIs, along with immature inventory management and a lack of internal communication, can contribute to creating countless shadowy endpoints. Below, I’ll review some of the issues that zombie APIs might cause and consider some actionable steps DevOps teams can take to prevent them.

    Understanding Zombie API Risks

    Forgotten APIs can cause a number of issues. For example, suppose an insecure testing environment was accidentally left exposed to the public. An attacker using automated endpoint scanning could find authentication and authorization holes to exploit, potentially exfiltrating sensitive data.

    It’s also a bad idea to let any piece of technology go unmaintained, given the daily influx of new exploits and vulnerabilities. This point is accentuated by the connected nature of APIs, which may plug into a vast network of databases and allow both read and write privileges to the backend infrastructure.

    Insecure APIs can cause a business both economic harm and damage reputation. Just consider the high number of API-related data breaches in recent years, which occurred at companies like Optus, Dropbox, Twitter and Zendesk. It’s even estimated that somewhere between $12 billion to $23 billion was lost in 2022 due to compromises in web APIs.

    Zombie APIs are an easy target for these sorts of cyberattacks because they tend to have insecure designs that are easier to crack. They also tend to use immature monitoring systems, which means hackers can act under the radar more easily than with actively used endpoints.

    Tips to Avoid Zombie APIs

    Keep an Active Inventory of APIs

    As they say, you can’t secure what you don’t know about. In fact, OWASP lists improper inventory management as one of the ten top API security risks. Therefore, proper inventory management is a good first step to avoiding zombie APIs. Scan your service portfolio for forgotten endpoints, catalog them and update the catalog regularly.

    It’s also a good practice to thoroughly document your services to aid in internal discoverability. If possible, adopting specification-first practices can also ensure the documentation and implementation are based on a single source of truth, thus avoiding mismatched versions and documentation drift.

    “The key to preventing zombie APIs is visibility,” said Jeremy Snyder, CEO, FireTail. “Many organizations lack ongoing, up-to-date inventories of all the APIs that are running in either production or staging environments.”

    Use Proper Versioning and Life Cycle Strategies

    Another method to reduce the chance of zombie APIs is to adopt mature API life cycle management practices. The chosen API versioning strategy should be clearly defined and codified. And versioning changes should be clearly communicated to all stakeholders.

    On that note, it’s just as important to plan out a sunsetting, retirement and deprecation strategy from the onset. Then, remove deprecated services when they have reached their end of life! This is not a glamorous task, but it should be baked into someone’s assignments.

    “Good cyber hygiene is an often overlooked strategy,” explained Snyder. “A second requirement is to have a policy around versioning and how many versions of an API can exist at any given moment. For instance, that policy may state that only the latest version can exist or the latest plus the previous. However, this relies on having visibility in order to maintain compliance.”

    Other areas of proper life cycle management include employing governance around development and deployment and utilizing automated testing in continuous deployment (CI/CD) pipelines. Both of these could help set policies and security requirements, which should also bolster API safety.

    Share Knowledge of Internal and Third-Party Services

    Tribal knowledge is the antithesis of DevOps culture. As such, it’s a good practice to de-silo and share internal knowledge of API-powered services to limit the propagation of rogue endpoints. This could be done through private network repositories or even an internal Postman Collection or Workspace.

    “Internal processes like organizational coordination and communication are critical,” added Snyder. “If teams don’t tell each other about new APIs being developed and launched into production, security teams can’t assess or audit them. Conversely, if app teams don’t know about network infrastructure resources designed to cover various API security aspects, developers don’t know what security controls need to be baked into the API code.”

    Visibility is Required to Avoid Zombie APIs

    A recent CISO survey revealed that API security was the number one concern for CISOs. For many reasons, web APIs are still low-hanging fruit for attackers. This is underscored by the 400% spike in malicious API attack traffic recorded by Salt Labs earlier this year.

    Many of these attacks, we’ve also learned, are occurring over authenticated APIs. This shows that greater accountability and visibility are required to begin to stem the tide of API-related security incidents.

    To reach an adequate level of visibility, leaders should consider adopting tooling that helps determine if there are outdated APIs or APIs with multiple live versions, said Snyder. “These tools should help display what security live APIs have and provide recommendations around how to fix them, if not providing the necessary code or modules to secure the APIs directly.”

  • Palo Alto Networks Extends CNAPP to CI/CD Platforms

    Palo Alto Networks Extends CNAPP to CI/CD Platforms

    Palo Alto Networks has extended the reach of its cloud-native application protection platform (CNAPP) to include the ability to secure continuous integration/continuous delivery (CI/CD) platforms.

    Daniel Krivelevich, CTO for application security for Prisma Cloud at Palo Alto Networks, said this extension of the Prisma Cloud platform would make it easier to better secure software supply chains as software builds are continuously updated by application development teams.

    Previously, Palo Alto Networks provided the ability to secure runtimes and secrets and scan code for vulnerabilities as it is being developed. This latest extension now adds the ability to secure the CI/CD platforms that drive DevOps workflows, he noted.

    While more organizations than ever are shifting application security responsibility further left toward developers, many of them overlook the need to secure the CI/CD platform itself. Most developers are not cybersecurity experts, so the chances they will miss something that can find its way into a software build are still high. Extending the reach of Prisma Cloud to the CI/CD platform will ensure the build that forms the foundation of the code is free of vulnerabilities when it finds its way into a production environment.

    That’s critical, because cybercriminals are becoming more adept at injecting malware into software supply chains in the hopes of being able to eventually compromise multiple downstream applications. In fact, this issue has prompted governments around the world to hold more organizations legally responsible for the security of the applications they build and deploy.

    There are, of course, multiple approaches to securing software supply chains, but Palo Alto Networks is making a case for an integrated platform that provides a comprehensive approach to securing the entire IT environment. Rather than integrating multiple point products, a CNAPP ultimately reduces the total cost of cybersecurity on an end-to-end basis, noted Krivelevich.

    It’s not clear how quickly organizations are transitioning to CNAPPs, but as that transition occurs, the overall state of application security should improve. One of the issues that has historically plagued application security is no one in an organization has been specifically tasked with ensuring it. Application development teams assumed cybersecurity professionals were allocating funds to it. Cybersecurity teams, however, tended to focus on areas they directly controlled, such as network firewalls. A CNAPP makes it simpler to deploy a cybersecurity framework in a more extensible way.

    Of course, there’s still much work to be done when it comes to prioritizing vulnerability remediation efforts. The truth is developers only have so much time to allocate to developing patches, so the focus needs to be on identifying the vulnerabilities that are the most severe in terms of the amount of damage that might be inflicted. At the very least, however, a CNAPP should provide the means by which the context required to identify those vulnerabilities could be more easily shared.

    One way or another, however, the number of vulnerabilities finding their way into production environments should steadily decline as more focus is put on securing software supply chains.

  • Deploying a Service Mesh: Challenges and Solutions

    Deploying a Service Mesh: Challenges and Solutions

    A service mesh is a dedicated infrastructure layer that enables communication between microservices in a distributed application. It helps to abstract the underlying communication infrastructure, such as network protocols and load balancing and provides a consistent interface for microservices to communicate with each other.

    In a service mesh, each microservice in the application is represented as a “service” within the mesh, and the mesh acts as a proxy between the services, routing requests and responses between them. It also includes a control plane, which manages and configures the proxy instances and provides observability and monitoring capabilities for the services.

    Some of the benefits include:

    • Improved observability: A service mesh provides visibility into the communication between microservices, which can be helpful for debugging and monitoring the performance of the application.
    • Resilience: It can help to make microservices more resilient by providing features such as retries, timeouts and circuit breakers, which can help to prevent cascading failures.
    • Security: A service mesh can help to secure communication between microservices by providing features such as mutual TLS (mTLS) and rate limiting.
    • Ease of use: It provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications.

    Why is a Service Mesh Important?

    A service mesh is important because it helps to abstract the underlying communication infrastructure for microservices-based applications, which can make it easier for DevOps teams to build and manage these types of applications.

    One of the main benefits is that it provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications. For example, a service mesh can provide features such as load balancing, retries and timeouts, which can be useful for ensuring the resilience and reliability of the application.

    It can also help to improve observability for microservices-based applications by providing visibility into the communication between the microservices. This can be helpful for debugging and monitoring the performance of the application, which can, in turn, make it easier for DevOps teams to identify and resolve issues more quickly.

    What are the Main Deployment Challenges?

    There are several key challenges that a DevOps organization may face:

    • Complexity: Service meshes can be complex to set up and manage, especially in large, distributed applications. This can make it challenging for organizations to implement and ensure that it is configured correctly.
    • Operational overhead: Service meshes can add a layer of complexity to the application stack, which can increase the operational overhead of managing the application. This can be especially challenging for organizations that are not used to operating one.
    • Cost: While service mesh software is typically open source, the need to run a sidecar container alongside every container can increase the compute capacity needed to run a Kubernetes cluster.
    • Integration with existing systems: They can be difficult to integrate with existing systems and processes, especially if the organization has not previously used a service mesh. This can make it challenging to get the full benefits.
    • Lack of expertise: Service meshes are relatively new technologies, and there may be a lack of expertise within the organization. This can make it challenging for organizations to get started and ensure it is used effectively.
    • Performance overhead: Service meshes can add a performance overhead to the application as they introduce an additional layer of proxying between microservices. This can make it challenging to ensure that the application is performant and scalable.

    Best Practices to Ease Service Mesh Pain

    Here are a few best practices that can turn service mesh deployments from a pain to a pleasure.

    Use Configuration-as-Code in a GitOps Approach

    Using configuration as code in a GitOps approach is a best practice to improve reliability and maintainability.

    GitOps is a way of managing infrastructure and applications using Git as the single source of truth. In a GitOps approach, all configuration and deployment information is stored in Git, and changes to the infrastructure and applications are made by committing code changes to Git.

    Using configuration-as-code in a GitOps approach can help to improve the reliability and maintainability of the service mesh in several ways:

    • Version control: Storing configuration-as-code in Git allows you to track changes to the service mesh configuration and roll back changes if necessary. This can help improve the service mesh’s reliability by making it easier to identify and fix issues.
    • Collaboration: Git allows multiple people to work on configuration at the same time, which can make it easier to collaborate on changes and ensure that the service mesh is properly maintained.
    • Automation: GitOps approaches often use automation tools, such as continuous integration and delivery (CI/CD) pipelines, to automatically deploy changes to the service mesh when code is committed to Git. This can make it easier to manage and maintain and can help to improve its reliability by reducing the risk of errors.

    Focus On Developer Experience

    Ensuring a positive developer experience is a best practice because it can help to improve the productivity and effectiveness of the development team. A positive developer experience means that developers can easily understand and use the service mesh, and that it does not introduce unnecessary complexity or frustration into their workflow.

    Here are some ways to improve the developer experience:

    • Provide clear documentation: It is important to provide clear and comprehensive documentation on how to use the service mesh, including examples and tutorials. This will make it easier for developers to understand and use.
    • Integrate with existing tools and processes: The service mesh should integrate seamlessly with the existing tools and processes that the development team is already using. This will help to minimize disruptions to the team’s workflow and make it easier for them to work with.
    • Provide support and training: It is important to provide support and training to help developers understand and use the service mesh effectively. This can include online resources, in-person training, and support from the vendor.

    Reduce Costs With Low-Cost Cloud CPUs

    A service mesh increases the cost of an entire containerized deployment because it requires deploying a sidecar container alongside all workloads. When running on Amazon Web Services (AWS), the AWS Graviton processor can ease deployment by reducing the cost of running service mesh infrastructure.

    The AWS Graviton processor is a custom ARM-based processor designed specifically for use in Amazon Web Services (AWS) environments. It is optimized for running workloads commonly found in the cloud, such as microservices and containerized applications.

    Using the AWS Graviton processor can help to reduce the compute costs of a service mesh because it is generally less expensive than other processors, such as Intel Xeon processors. The AWS Graviton processor is also designed to be highly efficient, which can help reduce the service mesh’s overall resource utilization. This can help to reduce the cost.

    Choose the Right Control Plane

    Choosing the right control plane is a best practice because it can impact the performance, reliability and maintainability of the service mesh. The control plane is the central component that manages the proxy servers and enables you to configure and monitor the communication between microservices.

    Here are some considerations for choosing a good control plane:

    • Compatibility: It is important to choose a control plane that is compatible with the rest of the service mesh infrastructure, as well as with the application and its dependencies. This will ensure that the control plane can operate effectively and support the needs of the application.
    • Performance: The control plane should be able to handle the traffic and data volumes of the application without experiencing performance degradation. It should also be able to scale up or down as needed to meet changing demand.
    • Reliability: The control plane should be reliable and able to withstand failures without interruption. It should also provide features such as circuit breaking, retries and timeouts to help improve the resiliency of the service mesh.
    • Ease of use: The control plane should be easy to use and understand, with clear documentation and a user-friendly interface. This will make it easier for the DevOps team to manage and maintain the service mesh.
    • Integration with other tools: It is important to consider how the control plane integrates with other tools and systems, such as monitoring and logging tools, and how it can be integrated into the overall workflow of the organization.

    Conclusion

    In conclusion, deploying a service mesh can be a complex and challenging process, but it can also provide significant benefits in terms of improving the reliability, scalability and security of a cloud-native application. 

    Some of the key challenges include complexity, operational overhead, integration with existing systems, lack of expertise and performance overhead. 

    To overcome these challenges, it is important to choose the right service mesh, use configuration-as-code in a GitOps approach, choose the right control plane and ensure a positive developer experience. By addressing these challenges and following best practices, organizations can successfully deploy a service mesh and reap the many benefits it has to offer.

    Image Source 

     

  • Fermyon Adds Managed PaaS for Building Wasm Applications

    Fermyon Adds Managed PaaS for Building Wasm Applications

    Fermyon Technologies this week launched a hosted platform-as-a-service (PaaS) environment, dubbed Fermyon Cloud, that promises to make it simpler to build WebAssembly (Wasm) applications.

    Announced during the Cloud Native Wasm Day event during the KubeCon + CloudNativeCon North America conference, Fermyon Cloud is now available in open beta.

    Fresh from raising $20 million in funding, Fermyon CEO Matt Butcher said IT teams can quickly build and deploy Wasm applications using a Fermyon Spin development tool and a Fermyon Platform the company launched earlier this year.

    Fermyon Cloud adds an opinionated PaaS environment managed by Fermyon that can start up Spin applications in less than a millisecond. It uses a serverless application programming interface (API) that makes it possible to cache and optimize applications as they are loaded, noted Butcher.

    Originally developed more than five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now used to rapidly build lighter-weight applications that can be deployed on any server platform. In effect, the promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

    Wasm isn’t necessarily going to replace existing approaches for building applications, at least not any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster.

    In addition, at a time when organizations are becoming more concerned about application security, the appeal of Wasm is clear. Existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. In contrast, Wasm code runs in a sandboxed environment that isolates execution environments to eliminate the ability of malware to laterally move across an application environment.

    Wasm is especially well-suited for building lightweight applications that previously might have been deployed on a serverless computing framework, noted Butcher. The issue developers are encountering when using a serverless computing framework is that those frameworks are based on containers that have comparatively slow startup times, he added.

    It remains to be seen how much traction Wasm gains in the months ahead, but Butcher said he expects most backend services, such as databases, will continue to be built using containers. Fermyon is betting, however, that many future cloud-native applications built by the average developer will be constructed using Wasm. In the longer term, Wasm will also soon be used to build applications infused with machine learning algorithms, said Butcher.

    In the meantime, DevOps teams should get ready for more Wasm code to move through continuous integration/continuous delivery (CI/CD) pipelines. The challenge, of course, is that code will need to be managed alongside all the other software artifacts moving through those pipelines, as well.

  • Protecting CI/CD Pipelines to Secure the Software Supply Chain

    Protecting CI/CD Pipelines to Secure the Software Supply Chain

    Cloud-native applications have become increasingly complex. Composed of an infrastructure stack of mash-up code, hundreds of open source and commercial components, services and APIs, today’s software supply chain is fraught with security risks. At the same time, the ability to manage existing application requirements while building innovation and taking on new areas of responsibility like security is stretching DevOps teams beyond their capacity. The concern for the number of connected and exploitable weaknesses across the software supply chain are now requiring organizations to take a proactive approach to protect their continuous integration and continuous delivery (CI/CD) systems, as they have become a target through which attackers infiltrate multiple production systems. But meeting this requirement is no easy feat as it often requires organizations to choose between how much security to enforce in the build cycle while quantifying their risk to build and deploy quickly. 

    A recent survey revealed that nearly all (97%) of an organization’s assets—and security issues—are now in the cloud. And yet, only 29% of an organization’s assets are associated with cloud-specific policies. Addressing this gap requires organizations to have a proactive approach to protect their technology infrastructure, especially securing the artery of their software supply chain: The CI/CD pipeline. By embracing new security and compliance strategies within their governance approach, organizations can better protect their CI/CD pipeline and cloud applications. 

    There is a growing shift toward programmable infrastructure and infrastructure-as-code (IaC) practices to build out infrastructure and manage configuration files. But with this practice comes the increased risk of exposing application credentials, API keys, encryption keys and digital certificates. Tools supporting the CI/CD pipeline have now become the artery of cloud applications, and it’s becoming more challenging to store, transmit and audit data securely. In addition, when CI/CD tools interact with other systems in the DevOps environment, it increases the risk of exposure for configuration files. A compromise in the build system, for example, can be used to get access to production systems that can result in the exposure of sensitive information or the injection of malicious code, corrupting the entire CI/CD pipeline and thus the software supply chain. 

    A recent Unit 42 Cloud Threat report revealed that overly permissive credentials created added risk opportunities in the CI/CD pipeline. The study found that 63% of IaC templates contained misconfigurations and 91% of container images contained high or critical security vulnerabilities. To address this, organizations need to catch security problems in the build process before cloud workloads are provisioned. During the SolarWinds compromise, for instance, attackers used custom malware designed for the company’s build cycle to observe each step. The sophistication of the intrusion in this attack during the software build process is a key lesson for DevOps and DevSecOps professionals and revealed how security needs to be approached. 

    One way to address this is by being able to identify CI pipeline misconfigurations, which can improve security in the software supply chain. Because CI pipelines are configured in the code, the same policy-as-code approach can be used to identify IaC misconfigurations or open source vulnerabilities to surface CI/CD weaknesses. DevOps and developer teams can keep configurations accessible to just a small group who are building for production release. By establishing enforceable permissions to the pipeline, there is better control over who can commit code changes to the repositories, create containers and deploy code to different environments. 

    Strong chains of trust throughout the build cycle are not commonplace today. But as organizations look at ways to strengthen their risk posture by shifting left, security and DevOps teams can work toward proactively hardening pipelines with the right CI/CD tools and frameworks and push the industry toward a more secure software supply chain. 

  • EvolveWare Further Automates App Modernization Tasks

    EvolveWare Further Automates App Modernization Tasks

    EvolveWare today announced it has added an Agile Business Rules Extraction capability to its Intellisys application modernization platform.

    EvolveWare CEO Miten Marfatia said the Agile Business Rules Extraction capability eliminates the need to freeze code development while applications are either being shifted to the cloud or refactored. Instead, the Intellisys platform will now keep track of updates to code and apply them once the application has been modernized, he said.

    Code updates can now be transferred automatically into the extracted business rules repository without affecting the rules that are not impacted by the updates. For rules impacted by the updates, a report is generated that highlights the changes. IT teams can now also update business policies and modernize applications concurrently via the repository that also keeps track of documentation such as diagrams, logic, database details and critical dependencies, said Marfatia.

    In addition to presenting logic in multiple formats, including pseudo-code, flowcharts, decision tables and business analyst language, it enables consolidation and optimization actions to be reverted to their original state if required.

    In general, IT teams have been struggling with application modernization efforts that require them to either lift and shift a monolithic application running in an on-premises IT environment into the cloud or refactor it into a set of microservices that run natively in the cloud. Eventually, most organizations will refactor monolithic applications, so the debate becomes to what degree to undertake those efforts before lifting and shifting an application into the cloud. Most monolithic applications were not designed to run in the cloud, so when the app is shifted it’s not uncommon for any number of performance issues to be encountered.

    EvolveWare claims that its Intellisys platform reduces the cost of application modernization by as much as 60% by eliminating much of the manual effort that would otherwise be required. Modernization efforts, in general, are hindered by manual processes that should be automated, said Marfatia.

    The issue that most DevOps teams encounter when modernizing an application is that it is not a task they regularly perform. As such, many of the processes required have not been automated with the same level of zeal they’ve applied to more routine manual tasks. The Intellisys platform is designed to enable IT teams to automate the most common tasks associated with migrating an application to another platform.

    The biggest driver of those migrations these days has been digital business transformation efforts that have accelerated since the start of the COVID-19 pandemic. Organizations of all sizes are moving applications to the cloud to ensure greater availability and resiliency to limit the amount of disruption that might be encountered should the pandemic worsen, or in case some other unexpected event makes accessing IT services difficult.

    The challenge, of course, is moving applications—and the database they depend on—from one platform to another is not easy. It can take some organizations months, sometimes even years, to make the transition. Given the backlog of applications that many organizations are looking to migrate to another platform, it’s clear there is a need for much higher levels of automation to accelerate a transition that, on its present trajectory, might take years to complete.

  • Why Object Storage is Best for Cloud-Native Apps

    Why Object Storage is Best for Cloud-Native Apps

    A crucial question that plagues cloud application developers is, “What kind of storage should we use for our app?” Unlike other choices like compute runtimes—Lambda/serverless, containers or virtual machines—data storage choice is highly sticky and makes future application improvements and migrations much harder.

    All three hyperscalers have storage services that present block, file and object-based data access. Each of these storage services are mature and offer different advantages, making the choice even harder. Though block and file-based storage has existed for multiple decades, in this article we will illustrate some key differentiators that should make object storage your default storage choice for new applications written in the cloud.

    Storage Type/Cloud Provider Google Cloud Amazon Web Services Microsoft Azure
    Block Persistent Disk Elastic Block Storage Disk Storage
    File Filestore Elastic File System Files
    Object Cloud Storage Simple Storage Service (S3) Blob Storage

    Easy Scaling

    Scalability is an important requirement for most cloud applications. It is expected that horizontally increasing the amount of compute power available to an application increases its ability to process requests, users, etc. to handle peak workload. Most cloud providers also make it easy to scale up compute resources to meet peak demand. As compute resources are scaled,
    block and file-based storage need to be mounted/attached to the new compute instances.

    However, a cursory search will show that these operations can fail or even hang indefinitely for multiple reasons. They also are often hard to debug. The other issue with using file and block storage solutions is that teardown of the compute instance may fail or hang for the same reasons. These issues immediately negate the application’s ability to scale freely as required. This is, however, not an issue with object-based storage, since there is no mount step involved. Your object storage is instantly accessible to the newly-created compute instances.

    Sharing and Consistency

    Data sharing and consistency are where object storage really shines compared to other storage types. In both block and file-based data storage, one instance of an application can end up seeing partial data written by another instance. Application developers end up having to use persistent locks to get around this issue. However, such schemes come with their own sets of challenges: Performance, correctness, etc. Persistent locks end up making an application severely complicated; I have seen even experienced storage engineers make mistakes while using persistent locks. Object storage avoids this problem by not exposing partially-written objects or objects actively being written. Also, note that objects are typically immutable, so once written they can only be overwritten as a whole and not in parts. This means updating data requires expensive read-modify-write cycles. However, most cloud providers help avoid these additional reads via special APIs that can create an object from portions of an existing object like GCS compose, Azure’s put page blob and AWS multipart upload.

    Data Protection

    Errors are bound to happen during application development or rollouts. These errors can end up impacting critical data and potentially disrupt normal application operations. This is why it is essential to have some sort of backup/snapshots configured on the storage that you use.

    Though most storage services have some form of backup/snapshot mechanism, most don’t make it very easy to configure or restore from them (that is, both require multiple steps or the involvement of a cloud administrator). All cloud object services support native data/object versioning capabilities which are extremely easy to enable. So, basically anytime an application updates and/or deletes, the object storage service preserves the older copy of the data. In case an older copy of the data needs to be restored, you can just read the old version and write it as the new object. The careful reader might see that if an application writes/deletes data often, there may be a lot of older versions of the data left behind. One might think these would be hard to identify and remove when not needed. However, all cloud providers support policy-based data life cycle management (see next section) so you can set up policies to delete unnecessary copies. Note that object versioning also provides an excellent defense against ransomware attacks.

    Policy-Based Data Life Cycle Management

    The amount of data being generated by applications is only going to keep increasing with each passing year. This is the reason all the cloud providers support policy-based data life cycle management for their object storage services. Even if you don’t expect to use more than a few gigabytes of data, policy-based life cycle management can help you keep your storage costs in
    check and can help reduce your code complexity around handling application crashes. Policy-based life cycle management especially comes in handy when you or your cloud admin decide to enable features like object versioning and object holds for data protection and compliance reasons. These policies are very simple to set up and can easily be customized to the needs of
    the individual organizations/applications/developers requirements.

    Conclusion

    As one can see from the above, object storage services have been built to enable the development of simple and scalable applications. So, if you are writing a new application from scratch, choose object-based storage to keep your applications simple and easy to maintain.

  • Survey Reveals High Cost of Application Modernization

    Survey Reveals High Cost of Application Modernization

    A survey of 250 software developers and architects in the U.S. found nearly three-quarters of respondents (74%) reported that the average cost of an application modernization project is nearly $1.5 million, with 79% noting that at least one of these projects has failed.

    Conducted by Wakefield Research on behalf of vFunction, a provider of a platform that automatically converts monolithic applications into microservices, the survey polled developers and architects at organizations with 5,000 or more employees that have been in business for at least 15 years and are maintaining Java applications. The survey found that the primary reasons application modernization projects failed were expectations not being set correctly (43%) and the need for organizational structural changes (37%).

    Despite the cost and inherent risks, however, the survey also found a full 92% of respondents planned to or are currently modernizing applications. Nearly two-thirds (62%) said having the right resources and tools is the key to application modernization success.

    Well over half of the respondents (58%) also noted that, on average, it takes 16 months to complete these projects, with more than a quarter (27%) noting it takes two years or more. Not surprisingly, a full 97% said they expected someone in their organization would push back on a proposed project.

    Application modernization, of course, is something of a catch-all phrase that can involve everything from providing applications with a web frontend to lifting-and-shifting them into the cloud or completely refactoring them to run natively on a cloud platform.

    vFunction CEO Moti Rafalin said that regardless of the scope of the initiative, most organizations should first pick these projects based on what makes the most sense for the business. Once identified, it then becomes critical for IT teams to have a deliberate strategy in place to achieve that goal given the high cost of failure, he added.

    Organizations would also be well-advised to determine how job roles will evolve, because one of the biggest inhibitors to application modernization is concern over how any job might be impacted, noted Rafalin.

    It’s not clear how quickly organizations are opting to modernize existing applications versus replacing them outright. However, as more organizations opt to run applications in the cloud, the level of interest in using microservices to build applications has risen sharply. The goal is to employ microservices to make applications both more resilient and secure. The tradeoff is that microservices-based applications tend to have lots of dependencies that make them more challenging to manage and secure.

    Regardless of approach, it’s more a question of when an application will be modernized or retired versus if. The level of technical debt that accrues over time for each application eventually becomes unsustainable. The issue, of course, is that most organizations don’t have the resources required to modernize every application at once, so it may take a decade or more to work through an entire application portfolio—even as that portfolio continues to grow. In fact, as technologies continue to evolve, it may turn out that application modernization is not a task to be completed as much as it is a permanent state of IT affairs.

  • 3 Steps to Jumpstart Your App Modernization Journey

    3 Steps to Jumpstart Your App Modernization Journey

    Like organizing your garage, modernizing your applications can seem daunting before you start, but you know it will pay off once done. So, instead of thinking about this project as a technical challenge, let’s look at it in the wider context of the business. Just as getting rid of old junk in your garage frees up the space you need for things you actually use, modernizing your apps helps your business run more efficiently and scale more easily. Based on my experience with many application modernization projects, here’s how developers can best approach app modernization, including what you’ll need from your team and technology, six key ways to tackle the task and how to prioritize.

    Start With a Business Assessment

    Before you can make any changes to your applications themselves, you need to lay out a plan based on your company’s needs. That means assessing every application in your portfolio, not just as individual properties but in the way they interconnect.

    Like most developers and engineers, when you have a technical background, it’s tempting to build a strategy around the most exciting technical opportunities. But the purpose of all the applications your company uses is to enhance the business. For example, your organization is likely considering an app modernization initiative to better serve customers and clients; to increase revenue or cut costs.

    That means when you approach modernization from a business perspective, you should prioritize apps based on business value. Large modernization projects can get complicated, so you won’t necessarily be able to complete this process for every app.

    When it comes to large-scale, complex applications, the effort required to modernize every piece is significant. So, it’s important to decide what applications are of the highest value and plan your modernization efforts starting there.

    There are several business-focused questions to consider, such as:

    • What are the business’ needs now and in the future?
    • Which problems are we trying to solve as an organization and as a department?
    • What capabilities does the business need to add in order to grow?
    • What does the business need to do to better support customers?

    Smaller organizations may be able to modernize every app and component. But if you’re in a large business or an enterprise, you will have to choose the apps and components that are most critical to the business goals. Of course, if you’re successful with the first crop of applications, it’s more likely you’ll get the go-ahead to move on to other apps and components.

    It’s important to stress how important this kind of assessment and planning process is. You need to get that business buy-in for that ultimate alignment and for delivering the most value for your business in the shortest amount of time.

    Choose Your Application Modernization Program

    Different applications require different modernization approaches, some of which are more labor-intensive than others. Here are six methods (the six Rs) used to modernize an app and how to assess which one is right in each case:

    • Retain: If an application is working as well as it possibly can in its current environment, leave it alone. This is rare, but it does happen.
    • Rehost: In the case of apps that already work well, you’re more likely to want to move them to a new platform than leave them completely untouched.
    • Retire: If an app no longer serves a useful purpose, is outdated or runs on technology that no longer exists, retire it.
    • Repurchase: Switching apps from perpetual licenses to software-as-a-service (SaaS), subscription-style models means less hardware maintenance, easier access to updates and cloud storage for all users.
    • Replatform: Transfer an app from a hardware-based option to the cloud, with a few small changes.
    • Refactor: The most work-intensive option—and the most interesting! This is the coding equivalent of a movie remake, in which you update the code to improve performance, availability, security and more.

    Follow App Modernization Best Practices

    All right. You’ve got leadership buy-in and you’ve categorized all your business’ apps according to the six Rs we mentioned above. Now, the real work begins. There are app modernization best practices to follow as you continue on this journey. Most importantly, remember that the effectiveness of your modernization efforts comes down to two key components: Your team and your tech. Here’s what you need from both for a successful mission.

    Deploy the Most Advanced Technology

    The underlying purpose of application modernization is to bring your apps up-to-date with the latest cloud technology. For the best results, you need to use the best available tech. There are a few elements of modern cloud technology you should consider. Serverless infrastructure is one. With serverless, you can make large-scale changes in real-time without having to maintain servers.

    Data management is another area where you should employ cutting-edge tech. You can use purpose-built databases that best suit different types of data for faster and more efficient processes.

    Autoscaling is also a key benefit of moving to the cloud. Be sure to factor in the need to scale from the start of your modernization project to avoid bottlenecks further down the line.

    Hire an Agile Team

    The most advanced tools in the world are useless if the people using them aren’t sufficiently trained or skilled. When hiring a team, look for agility. Application modernization processes are a lot of work. You need a team that moves quickly in order to hit your deadlines.

    Culture and responsibility, as well as ownership are also important. A demanding work environment requires open communication and people who will take responsibility for their part in the system. Consistency is another crucial factor. Involve the people who will be responsible for managing the apps from the start of the modernization process. This makes it easier for them to continue the work once the app is ready.

    Summary

    Getting the most out of your application modernization project requires the right tools, personnel and services. And while taking your first steps into the cloud can seem intimidating, by following tried-and-true best practices, you can stay on the right path toward a big payoff in the cloud.