Category: Blogs

  • Best Free Virtual DevOps Conferences to Attend in 2021

    Best Free Virtual DevOps Conferences to Attend in 2021

    New year, new beginnings and new conferences. It’s that time of the year again, to review and research upcoming events for 2021. Of course, given the ongoing COVID-19 pandemic, we’ll cover only virtual conferences. Here are the top five best DevOps virtual conferences you can attend for free. Just sign up, reserve your seat and attend, it’s as simple as that. 

    Why attend virtual conferences?

    Conferences provide wide visibility into market trends. As an individual, it’s impossible to know everything that is happening around the industry, especially the software industry. Conferences give us a chance to see things from different perspectives. Knowing how others are solving their engineering problems, what best practices they are using, how they deploy to production, etc., gives us the confidence to tackle our own problems. Demos, practical approaches and learning from top experts and speakers is yet another advantage for conference attendees. As the world has gone virtual, it has become easier to attend conferences via our laptops/desktops, right from the comfort of our home office. 

    So, let’s consider some of the industry’s best DevOps conferences this year.

    swampUP

    Date: May 25 – 27 (AMERICAS) | June 1-3 (EMEA)

    devops epicenter conference

    swampUP is one of the most recognized global DevOps conferences meant for DevOps practitioners around the globe. This conference puts you at the center of DevOps.

    It’s about all the stuff you ever wanted to know and understand from an engineering perspective. It empowers the attendees with actionable tips, patterns and use cases to drive DevOps initiatives with modern CI/CD, package management and security best practices. swampUP enables attendees to talk to the leading DevOps gurus live and benefit from their insight. 

    What is unique about this conference?

    The conference also includes three full days of hands-on DevOps training, keynotes, breakout sessions, real-world use cases with renowned speakers and brands and comprehensive, deep-dive tutorials. 

    DevSecOps Days

    Date: March 5, 2021

    devsecops days conference

    DevSecOps Days is a renowned conference that takes place in various cities and is organized around the latest security best practices in DevOps. Topics and talks center on adding security to DevOps. This conference aims to educate, share knowledge, evolve and explore DevOps and DevSecOps technologies and concepts, keeping security the focal point in software development. That’s what we call developing security as code. Volunteers from the local community organize the event. 

    What is unique about this conference?

    Attendees of DevSecOps Days will get a chance to talk to the industry’s leading security practitioners, and come away with insights about implementing security, automating security, overcoming challenges in DevSecOps and scaling security best practices. 

    DockerCon

    Date: May 27, 2021

    dockercon conference

    Docker is the tech that popularized container technology. If you are a DevOps enthusiast and want to know more about working with container tech, DockerCon is the conference for you. So much is happening around Docker these days, and it is worth your time to attend the event. DockerCon is an industry-recognized conference that offers:

    • Technical demos of container technology products and innovations from Docker and their partners. 
    • In-depth, real-world Docker use cases and examples of how others are using it to streamline software development. 
    • Technical sessions from Docker experts and captains and notable leaders from across the industry.
    • A chance for the community to come together and connect with collaborators around the world.

    What is unique about this conference?

    The conference is for everyone from beginners to experts. This is a great opportunity to hang out and chat with Docker experts and Docker captains. 

    DevOps World

    Date: September 22-24

    DevOps World 2021 conference

    DevOps World  is one of the premier DevOps events, bringing together DevOps thought leaders, software practitioners, developers, contributors and the entire DevOps ecosystem in one place. What else can attendees expect? 

    Aside from interacting with industry experts, it provides attendees the opportunity to learn, share, explore and help mold the future of software development and delivery best practices.

    What is unique about this conference?

    Attendees get hands-on experience with various new DevOps technologies and can make new connections in the industry.

    cdCon

    Date: June 23 – 24, 2021

    cdCon conference

    cdCon is a two-day virtual conference on delivering software with security and speed. It is a global conference featuring continuous delivery thought leaders, industry experts, practitioners, open source experts and developers delivering world-class talks. Attendees get to be part of the conversations driving the future of software delivery, enterprise leadership and open source technology.

    What is unique about this conference?

    cdCon is the best place for networking with industry thought leaders. Attendees will learn the latest trends in software delivery from experts. Meet and explore open-source technologies with other practitioners and enthusiasts. 

    DevOps India Summit

    Date: August 27-28, 2021

    DevOps India Summit conference

    One of the APAC region’s top conferences is DevOps India Summit.

    The conference theme this year is “Adapting to Industry 4.0 with DevSecOps, SRE, AI/ML/IoT and Data Science.” This conference focuses on broad topics related to SRE, data science and DevSecOps. It emphasizes Industry 4.0, which refers to the fourth industrial revolution focused on the rising trends in automation, IoT, big data, AI and cloud computing technologies.

    What is unique about this conference?

    The conference features industry leading speakers and panel discussions, and it enables attendees to interact with sponsors, attend yoga sessions, a party with a DJ, fireside chats and much more. 

    Let’s make 2021 an amazing year for DevOps by attending some great conferences, learning new technologies and adopting them into your organizations to solve engineering problems. Happy DevOpsing!

  • Using IBM ADDI and VTP to Enhance Observability in Mainframe Development

    Using IBM ADDI and VTP to Enhance Observability in Mainframe Development

    Observability has always been a key factor in software development – not so much on the mainframe. However, the rise of the internet as the go-to platform for modern commerce has caused an explosion of transactional activities. There’s much more complexity behind the scenes than the request/response activity that used to be the usual interaction between a client and a single server. That necessitates ubiquitous observability as a mission-critical necessity for any modern application. As computational activities increase, so, too, does the risk of failure. One way to avoid disaster is to rely upon observation technologies that monitor not only runtime behavior, but design-time behavior, as well.

    Analytical Insights are Key to Application Modernization

    IBM observabilityModern computing activity goes well beyond simple request/response interactions. Today, one request can traverse any number of computing resources before resolving to a completed response. These resources range from application logic that’s encapsulated and then exposed to the network at a number of endpoints, to a diverse mixture of data storage mechanisms. And, if the application is part of an event-driven architecture in which messages are passed around to a large number of recipients, ancillary logic can be executed in ways that are unknown to the originating request. This can cause significant side-effects, nonetheless.

    Given the complexities inherent in modern applications running at web-scale, without ubiquitous observability, developers are flying blind. This is true not only for what we have come to know as commodity computing, in which applications are hosted on racks of X86 servers housed in private and public data centers but also for mainframe computing.

    The Emergence of Observation Technologies

    Over the last decade, a growing number of observation and monitoring technologies have emerged for network applications and database environments. Open source projects such as OpenTracing, OpenTelemetry, and Prometheus give developers insights into the runtime behavior of applications. Also, there are a plethora of commercial observability products that companies can buy to meet their specific monitoring and observability needs.

    At the development level, there are open source tools such as JSHint for JavaScript developers, PyLint for Python developers and FindBugs for Java developers, just to name a few. These tools can inspect static code and point out shortcomings. Some tools, such as .NET analyzers, will go as far as to correct code as the developer is writing it. The easiest bugs to fix are those that are never created. Correcting code as it’s being written brings a whole new dimension to design-time observability.

    However, while the X86 development community has benefited from observability tools for a while, their mainframe counterparts haven’t had it so easy. Commodity developers require nothing more than a click on a web page link to access any number of powerful observability tools, but mainframe developers have been starved for these types of tools.

    Until now.

    Applying the Principles of Observability to Modern Mainframe Development

    One of the big challenges of mainframe programming is getting a clear picture of application dependencies. Unlike programming under Java, C# or Node.JS, where external dependencies are defined in a central configuration file, or internal dependencies can be discovered with a code analyst tool, mainframe programming makes knowledge of dependencies a difficult undertaking. This type of design-time observation hadn’t really existed until technologies like IBM’s Application Delivery and Discovery Intelligence (ADDI) came along.

    An important thing to understand about dependencies in most mainframe computing is that they exist at both the function and executable levels. A developer can create a function, which, in mainframe parlance, is called a routine. That one routine might be used by dozens, if not hundreds, of other routines. Sharing code from a common resource is not unusual in X86 development, where binary libraries get shared all the time. However, in mainframe computing, these shared routines, along with file layouts and resource definitions, are physically copied in with the developer’s code using a technology called a copybook. Then, the code is compiled and linked to create an executable file. Once turned into an executable, the code becomes opaque. As a result, observing what’s going at runtime and design-time within the executable can be a herculean task. For many years, it was.

    Fortunately, you can use a tool like ADDI to overcome this obstacle. IBM’s ADDI provides important insights and analysis into the code that makes up a mainframe application. Both developers and system analysts can use ADDI to determine not only application dependencies but also to gather information about the execution environment; for example, scheduler settings and database configuration.

    As with X86 development where ancillary application intelligence, well beyond information about the source code, can be displayed in the developer’s integrated development environment, ADDI also makes it possible to report information in the developer’s IDE. Also, systems analysts can use the additional information provided by ADDI, such as the structure and segmentation of an application, to make decisions about how to refactor code when it comes time to make improvements.
    Providing a broader scope of observability into design-time activity is but one aspect of enhanced observability in the modern mainframe environment. ADDI also reports test coverage metrics. Knowing what and how much code has been tested is an important part of observability, even more so when used with tools that are focused on mainframe testing. One such tool is Virtual Test Platform (VTP).

    Leveraging Observability in the Mainframe Testing Process

    Until VTP came along, mainframe developers were flying blind – they had limited visibility into the transactions that their code used and the dependencies that their code relied upon. They had an enormous amount of work to do to figure out transactional behavior throughout the application. They spent a lot of time doing archeological digging in legacy codebases to get a clear idea of what was happening. And, it didn’t get any easier as testing demands on all types of applications, both X86 and mainframe, increased due to the rise in commercial activities on the internet at a global scale.

    According to Chris Trobridge, senior offering manager at IBM, “The testing load for developers has been increasing tremendously, and with the introduction of agile development processes, developers just can’t keep up with the testing load that they have.”

    VTP addresses many of these testing issues, both in terms of observability and quality assurance. “VTP really is observing what goes on at runtime, but without knowing anything about the application,” Trobridge said.

    VTP can monitor an application and capture and record all its interactions. This type of observability enables developers to make modifications and then run those changes against observed behavior. It’s a novel approach to mainframe development in which the benefits of both design-time and runtime observability are leveraged in a synergistic manner. In order to understand how groundbreaking this capability is, you need to remember that only five years ago, while X86 developers were enjoying a maturing set of monitoring and tracing tools; for mainframe developers, this type of observability wasn’t possible. Now it is. It’s a dramatic step forward.

    “VTP is a tool that enables developers to automate a lot of the testing, and, in turn, enables the recording of a transaction environment without having to know a lot about the environment,” Trobridge explained. “The recordings themselves can be played back rapidly without compromising security. This is an important aspect of VTP. This level of observability and interactivity really is something that mainframe developers have not had access to before. It’s a transformational technology in the mainframe world.”

    Technologies such as ADDI and VTP are a transformational approach to enhancing observability in mainframe environments. In many ways, the focus on exposing the granularity of computing at the routine level is a harbinger of things to come for all developers, in both the X86 and mainframe worlds.

    Taking a Function-Centric Approach to Observability

    Historically, for commodity developers, observing request/response behavior between services at runtime, along with identifying code quality and complexity issues at design time, allows for identification and remediation of most issues in software development.

    For the mainframe developer, request and response behavior is only the tip of the iceberg when analyzing application behavior. In a mainframe environment, one sub-routine might be used by thousands of other functions and subroutines at any given time. Commodity developers have been spared the burden of accommodating the function as the fundamental deployment unit because, until recently, functions were grouped into well-encapsulated deployment units, such as Java’s .jar file, .NET DLLs or, more recently, containers. If something went wrong, the error would generally appear in one of the deployment units.

    However, with the current rise of serverless computing, where the function becomes the primary deployment unit, X86 developers are in the same boat as their mainframe counterparts. In the past, for the X86 developer, one application might use a limited number of components that could have dozens, maybe hundreds of functions. Now in the serverless world, all these functions are exposed as standalone units, in which each function is the responsibility of a distinct team. We’ve gone from an ecosystem that has a limited number of deployment units to an ecosystem that can contain thousands. Fixing bugs can require hours of poring over logs and examining minute details just to determine the root cause of an issue.

    As mentioned above, this depth of dependency at the function level is something that mainframe developers have been dealing with for years. Fortunately, tools such as ADDI and VTP provide a high degree of observability for very complex mainframe applications at both runtime and design-time.

    It’s strange to say, but the large, function-based ecosystem issues that mainframe developers are solving today will become a growing concern for X86 developers in the very near future. In many ways, tools such as ADDI and VTP are setting an example for X86 tool development moving forward. The mantra, “You can’t fix what you can’t see” is as true today as it has ever been. That the mainframe community is at the vanguard of creating new ways to work in massive computing environments is a testament to the power of rejuvenation in the most unexpected ways.

  • Transforming Your Digital Transformation

    Transforming Your Digital Transformation

    Change is difficult, so most companies pull the bandage slowly, hoping to avoid the hard, painful part – especially with regard to digital transformation. But in the corporate world, cautious change inevitably leads to entropy. Progress gets made in one department at a time, at the expense of others. Leaders turn over, priorities shift, plans fall apart and the desired results never happen. The bandage never really comes off.

    I see this happen a lot in companies that say they want to transform their digital customer experience – across all industries we work with. The board or the shareholders might not embrace a truly digital-first strategy or understand what the end-state transformation goal actually is. Instead, they end up digitizing the past, refreshening a longstanding brand with a new storefront in a doomed effort to maintain business-as-usual.

    These companies start with a well-meaning internal innovation team. They preach agility, then spend months researching the problem and consulting internal stakeholders, all the while trying to stay close to their comfort zone of existing practices. They write reports, they create roadmaps, run design-thinking workshops and come up with a solution … and then throw it over the wall to IT and wash their hands of it. Nine months later, the team is busy executing the new plan, but, with no internal champion, it can’t innovate. Due to the chaos and complexity of the project, the company burns through its budget and the project becomes a sad statistic. In fact, 95% of corporate digital transformations fail outright or produce diluted results, according to one recent study.

    Shrink the Transformation Timeline

    If a company really does want to digitize for the future instead of the past, it needs to turn that approach on its head. It needs to drastically shrink the timeline for digital transformation, which means starting with a digital operating model and putting the end clearly in sight.

    The result is a digital operating model that continuously delivers and measures value. It’s not a project. It’s not a product. It’s an operating model that puts teams close to the market and customer, and makes them responsible for finding and delivering innovative, high-value customer experiences.

    Get the Team Right

    This approach requires a team that knows how to embrace ambiguity and takes responsibility for creating the solution, not just designing it or building it – both of which fail when done in a silo.

    It needs to be a small, multifunctional team with the authority to implement things quickly, with the fewest possible hoops to jump through along the way. And when the inevitable organizational friction arises, the team and its goal needs to be seen as a transformation opportunity, not a barrier to be avoided.

    Companies assume they can do this work in-house, but it’s next to impossible to form the right internal teams because, typically, they don’t have enough experience with this model.

    These internal teams don’t quite have the right training for the job, but more importantly, they don’t have the right permission and agency. Some are risk-averse or can’t break through organizational silos. Some simply aren’t given the agency to do the work. Organizations with a lot of experience evolving, that give their employees this agency as a matter of course, might have success in-house. But it’s a tough ask for older, established firms.

    Don’t Design – Execute

    To their credit, many companies see this and outsource their transformation leadership to a consultancy firm. But you can’t outsource a transformation. You can’t teach a transformation. You need to implement transformation.

    Both internally and externally led transformations fail to grasp what really makes transformation work: agency and delivery.

    Instead of researching, planning and announcing, the team needs to roll up their sleeves and start executing. They have to drive the evolution of the company’s software toward the identified goals, break down any organizational silos or challenges that get in the way and deliver – quickly. They have to work together with the IT team, and anyone else who needs to understand what they’re doing, but execution needs to be top of mind at all times.

    The solution isn’t insourcing or outsourcing. It’s a joint venture, where the transformation is within the company’s core business unit, working together with a consultancy or partner to complete the digital transformation faster by focusing on a smaller slice of the business. With this foundation, an organization can be pulled through a rapid transformation in nine to 18 months, rather than three to five years.

    In fact, in under six months, a tiny transformation team of five to seven people can scale up to a transformed organization of 120 people, quickly delivering the desired digital-first customer experience. All it takes is a team that has done it successfully, multiple times. And the best thing about this is that transformation is measurable by the ability of teams to continuously deliver and evolve experiences across multiple digital channels.

    Digital moves too fast, and is too complicated, to be managed by traditional processes and approvals. If it does, whatever change your company sets out to enact is at risk of being dead on arrival. Agency plus delivery is the formula for a successful digital transformation.

  • HashiCorp Expands Managed Services Offerings

    HashiCorp Expands Managed Services Offerings

    HashiCorp today announced the general availability of its Consul service mesh as a managed service on the HashiCorp Cloud Platform (HCP) along with a beta release of a managed instance of HCP Vault, a secrets management platform, on HCP.

    HCP is currently hosted on the Amazon Web Services (AWS) platform, on which the company is making available its complete portfolio as a managed service. In the longer term, HashiCorp plans to make its managed services available on all the major cloud platforms.

    Chris Kent, director of product marketing for HashiCorp, said despite the growing number of open source service mesh alternatives, many organizations would prefer to employ a service mesh provided by a single vendor that they didn’t have to provision and maintain. HashiCorp’s Consul service mesh provides a lightweight alternative that enables service-to-service networking and security via connection authorization and encryption and spans both Kubernetes clusters and virtual machine platforms using the mutual Transport Layer Security (mTLS) protocol.

    Applications can then employ sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without ever having to directly interface with Consul itself.

    HashiCorp is making the case for Consul at a time when internecine warfare is raging between proponents of open source service mesh platforms such as Istio, Linkerd and Kuma. The Consul service mesh provides an alternative that is simpler for developers to incorporate across both microservices-based applications running on a Kubernetes cluster and legacy monolithic applications running on virtual machines, Kent said. In contrast, Istio and Linkerd are designed solely for use in Kubernetes environments.

    It’s still the early days of service mesh adoption. In addition to simplifying application traffic routing between services, one of the other benefits of service mesh is that it provides a layer of abstraction above lower-level network application programming interfaces (APIs) and protocols that is more accessible to developers. As developers become more familiar with service meshes, the ability to programmatically include network and security operations within a DevOps workflow will grow. HashiCorp is collectively positioning Consul and Vault as foundational components for creating a zero-trust architecture.

    In the meantime, each IT organization will need to determine which type of service mesh makes the most sense for their environment. In many cases, organizations may find themselves employing multiple service meshes to address different use cases. Regardless of which they choose, service meshes will soon become a permanent fixture in the proverbial solar system around which IT services revolve.

    HashiCorp claims that more than 2,000 organizations signed up to participate in the HCP Consul and HCP Vault beta programs. That level of interest suggests interest is growing in consuming IT as a service rather than as a platform that requires deployment by an internal IT team. It remains to be seen the degree to which organizations will prefer to consume those services directly from a vendor, versus a cloud service provider or third-party IT services provider.

  • Atlassian’s Shift to the Cloud Gets Underway

    Atlassian’s Shift to the Cloud Gets Underway

    Atlassian today announced the general availability of Cloud Enterprise, a cloud-based service through which organizations can mix and match the company’s various offerings under a single subscription.

    The company has signaled its intention to shift toward cloud services for months; now, the initial Cloud Enterprise subscription will cover the company’s Jira Software, Confluence and Jira Service Management offerings.

    Bala Venkatrao, head of product for Enterprise Cloud at Atlassian, said the goal is to make it more cost efficient for organizations to consume the company’s software versus merely acquiring a license to deploy software in an on-premises IT environment.

    The company is also making controls available that enable governance of user and change management via a centralized admin hub. Administrators can assign users to instances, configure security policies and monitor usage trends through the hub. There are also built-in integrations with third-party identity-as-a-service providers, to enable administrators to automate provisioning and de-provisioning.

    Administrators can also set up and customize multiple application instances; they can keep data pinned to different regions to customize those instances with specific marketplace applications or configurations for compliance purposes.

    Finally, a marketplace will allow IT organizations to expand the number of applications they consume from Atlassian and its partners. A smart links and app switcher capability for Jira and Confluence Cloud enable easy collaboration across different instances of Atlassian applications.

    Atlassian currently has more than 194,000 customers, so it may take some time to transition the existing installed base to this model. In the meantime, Atlassian is pushing as many new customers as possible toward a cloud platform that makes it easier for Atlassian to keep customers current on the latest release of its software. Atlassian plans to support up to 20,000 users per application instance by later this year.

    Venkatrao said while the Atlassian portfolio is frequently consumed by individual end users, the Cloud Enterprise offering is designed to appeal to CIOs, and other senior level executives, that want to centralize billing for application services now accessed via the cloud. That approach will make it easier for large organizations to take advantage of discounts they may qualify for as overall usage increases, Venkatrao said.

    While Atlassian may be a little late to the software-as-a-service (SaaS) application game, Venkatrao noted that the Cloud Enterprise platform will make it simpler for Atlassian to apply AI to the metadata it will collect. Atlassian has already leveraged AI to improve document search within Confluence and Jira, in addition to employing predictive analytics to surface recommendations for including personnel on a project.

    It may be a slow transition to the cloud for Atlassian, but that transition is clearly underway.

  • Tidelift Secures Open Source Software Supply Chains

    Tidelift Secures Open Source Software Supply Chains

    Tidelift today announced the general availability of a platform dubbed Tidelift catalogs, through which enterprise IT organizations can more effectively manage their open source supply chains.

    Donald Fischer, Tidelift’s CEO, says the Tidelift catalogs platform enables IT teams to curate, track and manage open source components that have been vetted and adhere to compliance requirements by Tidelift. The company is working directly with the maintainers of those open source projects to compensate them for making that additional effort, said Fischer.

    Developers can reliably pull components spanning common language frameworks like JavaScript, Python, Java, Ruby, PHP, .NET and Rust, with more programming environments to follow, added Fischer. Those components are made available via a Tidelift Subscription service.

    Fischer said Tidelift is going beyond merely scanning open source components for vulnerabilities. The company is ensuring that when developers access versions of open source components, those versions comply with specific sets of policies, said Fischer. As a part of that subscription service, Tidelift monitors components for vulnerabilities as they are discovered, and works with maintainers to implement updates as needed.

    While many organizations are starting to employ DevSecOps best processes, Fischer said the discovery of an issue involving open source components often comes far too late in the process. The Tidelift catalog approach ensures there are no last-minute surprise that are only discovered just before an application is about to be deployed in a production environment.

    Securing software supply chains has become a higher priority since it was revealed that cybercriminals successfully inserted malware into an application update made to network monitoring software provided by SolarWinds. That malware subsequently rippled across IT environments involving multiple corporate entities, as well as several Federal agencies.

    Of course, securing a software supply chain doesn’t happen overnight. Most IT organizations don’t have the processes and platforms required to vet open source components and frameworks. Tidelift is betting most of those organizations would prefer to subscribe to a service, rather than set up that infrastructure themselves. However, for organizations that require in-house monitoring of all the elements of their application development platform, Tidelift will make an on-premises edition of its platform available.

    As organizations become more dependent on software, the potential impact malware can have on their operations can be extensive. Organizations of all sizes should expect to be fielding inquiries from customers, suppliers and partners concerning the level of rigor being applied to their software development processes. In effect, they are going to demand to know the provenance of the software they are being asked to implicitly trust. In many cases, those inquiries will provide the incentive to accelerate adoption of DevScOps best practices.

    The days when organizations blindly used software with little regard to its origins are coming to a close. That doesn’t mean reliance on open source software is necessarily going to decline; however, it does mean application development teams will be held more accountable for the open source components they rely on.

  • vFunction Automates Conversion of Java Apps to Microservices

    vFunction Automates Conversion of Java Apps to Microservices

    vFunction has developed an eponymous platform capable of automatically converting a monolithic application written in Java into a set of microservices. The startup is emerging from stealth mode today.

    Fresh from raising $12.2 million in seed funding, vFunction CEO Moti Rafalin said the company’s platform employs dynamic analysis, static analysis, data science and automation to enable IT teams to reengineer, in a repeatable fashion, the source code used to create monolithic Java applications.

    As part of that process, vFunction also detects and eliminates code that is no longer executed to reduce the footprint of an application, minimize security risks and overall maintenance tasks.

    The vFunction platform is deployed as a server that communicates with agent software injected into the legacy monolithic application. The server then creates a microservice that is scanned by additional tools to determine how best to optimize it to run on, for example, a Kubernetes cluster based on the Red Hat OpenShift platform, said Rafalin.

    IT teams can also employ vFunction to determine which monolithic applications are better suited to being converted into a set of microservices that can be automatically extracted into separate compilable projects. Each project comes with an estimated timetable for completion that can be accessed via a Modernization Factory Dashboard and Application Complexity Assessment tool provided by the platform.

    Rafalin said most monolithic applications are made up of large amounts of ‘spaghetti code’ that was added over multiple generations by different development teams. Manually analyzing that code as part of an effort to refactor a legacy application would require weeks of effort, Rafalin said. As such, the rate at which most organizations are re-engineering applications is extremely slow, he said.

    In fact, it’s not unheard of for IT organizations to to start, but quickly abandon such because the time and effort required proved too costly. vFunction claims its automated, domain-driven processes accelerate manual refactoring by a factor of ten, resulting in a savings of anywhere from $300,000 to $500,000 per application.

    Pricing for vFunction is based on a per-application model. The company has also established alliances with system integrators such as HCL Technologies, Tata Consulting Services and Wipro that are regularly contracted by IT organizations to refactor their applications.

    Of course, not every monolithic application needs to be converted into a set of microservices. However, most monolithic applications have components that would be easier to maintain and support as a distinct microservice. Organizations, in general, are embracing microservices to build applications that are more resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than crashes altogether. The challenge is that, over time, the dependencies that can exist between hundreds of microservices can be more challenging to manage than those of the monolithic application being replaced.

  • The Chaos Mindset: Teaching Your Code to Cope

    The Chaos Mindset: Teaching Your Code to Cope

    Chaos engineering sounds alluring and exciting—it’s fun to experiment, right? But what some misunderstand about this approach is that it’s not about moving fast and breaking things. It’s about designing and introducing disruptions in the software production process that tests the resiliency of the code, much like crash testing in the automotive industry.

    If you think about it, this is the logical extension of the way developers like to think anyway: we’re designing software and systems for the real world. Shouldn’t they be able to handle real-world situations?

    To design effectively for the real world, developer teams don’t necessarily need to become chaos engineers. This isn’t about training for an entirely new set of skills. Rather, it’s about adopting a chaos mindset—a set of systems and perspectives that lets your team engage in controlled experiments to deliver products that can cope with whatever end-users throw at them.

    So, how do you know if your team is ready to adopt chaos engineering principles? And what should you do to help them?

    Chaos Engineering: The Basics

    This approach is all about using distributed systems as a “safe” experimentation environment, so that dev teams can ensure their products will withstand unexpected turbulence in production. Netflix engineers get the credit for coining the term, based on their experiences developing for Netflix on AWS.

    The fun part of chaos engineering is that it lets developers find loopholes in existing systems that allow them to develop for resiliency. By running experiments within existing platforms in a distributed environment, or within a sandbox development environment, teams can supervise and control the experiments without impacting end users.

    Some applications, such as transactional applications in finance or trading, should not be disrupted in production, and developers should test in a sandbox environment instead. Chaos engineering is very easy to put in place if your team uses containerization techniques already – which should be part of any modern DevOps CI/CD process anyway. It is common to setup a DevOps CI/CD pipeline to run a battery of tests on an application before it gets to the publish step. Within that testing step, you can easily add some disruptions; some may be harder to put in place and require a more elaborate environment.

    Dev teams can use existing environments and systems to show each other how unexpected issues could impact production of a software product, allowing them to collaborate and solve the coding mystery before it slows or stops production entirely.

    Applications designed by engineers are subject to common issues, whether the applications run on-premises or in the cloud. We can group these issues into the following categories: hardware limitations, sub system failures, external system failures and software bugs. While we could define more categories, these are the main ones, and the ones that are easy to test.

    Chaos Mindset: The Tao of Chaos

    Like Agile, chaos engineering is more than a set of activities and workflows—it’s also a state of mind. Your people and your culture must be ready and able to adopt chaos principles, as well as chaos processes.

    For the DevOps leader, adopting a new mindset might sound a little, well, vague. But this shift is based on concrete actions, not just philosophical musings.

    Consider an example from the world of cloud infrastructure: a mission-critical application that is hosted within a cloud service could be at risk for failure if, say, that cloud service is centralized in a single location, or within a limited number of microservices within the cloud infrastructure. But if the app is hosted in a distributed way, you can create greater opportunity for application-level availability and resilience, and you can test for that resilience within the existing production environment.

    This kind of distributed architecture isn’t brand-new for most enterprises, and, therefore, the process of developing applications in way that tests for availability in a variety of infrastructure scenarios also shouldn’t be a foreign concept. As a DevOps leader, you can build a culture of resilience-centric thinking by empowering your teams with the tools they need to adopt chaos-style testing, and then showing them how to build that thinking into every sprint and every standup.

    It takes work to train your teams, but you don’t have to do it alone. Netflix’s Simian Army has tons of tools and guidance; Facebook Storm and Amazon Gameday, both war room-type experiences to simulate failures in the cloud, also have helpful examples and ideas.

    Chaos Engineering in Real Life

    Deploying a chaos-inspired experiment strategy isn’t easy. Start with a simple set of operating principles as a guide for designing your chaos strategy:

    • Hypothesis: How we think the system should work, so we know when it doesn’t work.
    • Scenario planning: What are the possible failure events or crisis points that you know can happen in the real world?
    • Set up the experiments: Design and put in production the tests that measure the code’s strength.
    • Configure monitoring: Monitoring will help test the hypothesis and help you see, in real time, the impact and resolution of the disruption.
    • Make the experiment run itself: Automating the tests lets you continuously assess both performance and resilience.
    • Contain the experiment: You don’t want software that’s already out in the wild to get disrupted by your lab experiments, so make sure to design with guardrails in place.
    • Shut-off switch: Even when contained, have a shut-off switch to prevent the disruption from further impacting some users.

    The fundamental irony of chaos engineering is that it’s anything but chaotic. It’s a disciplined approach to breaking things that lets your team get smarter, faster, about how their products and applications will work in the real world. It’s a strategy that harmonizes beautifully with Agile practices. And even though it won’t make your apps bulletproof, it can definitely help you dodge the bullets of failure with greater grace and finesse.

    You must look at the software architecture as a whole to find the most appropriate chaos engineering testing tool for each portion of the architecture. There isn’t a single tool that can test all the components of your architecture; you will have to use different tools for different parts – and don’t forget monitoring! It’s only through proper monitoring that you can assess how the software is behaving in response to a disruption.

    Sometimes, the best approach, and the simplest one, is to build some chaos engineering steps into your software so that the software itself can be disrupted given specific inputs without exposing a security weakness in an obvious way. This is very much like how cloud applications create heartbeat and health check endpoints. We like to think about chaos engineering as a great complement to unit testing and integration testing, except we run it on production systems.

  • The No-Code Revolution: 5 Industries That Will Win Big

    The No-Code Revolution: 5 Industries That Will Win Big

    The year 2020 tested the mettle of countless businesses and industries, but those who were able to stay afloat had one thing in common: the ability to adapt to an increasingly digitized world by embracing future-facing technology.

    For companies already steeped in the tech world, these changes came more naturally, but not all industries were equally equipped to transform. For those caught on their back foot, the key was to apply existing technologies to old systems and analog problems.

    No-code platforms quickly shot to the fore of these innovative solutions, and their importance will long-outlive the pandemic that was the catalyst for their growth. At its core, the no-code revolution is leveling the development playing field and lowering the barrier to entry of digitization. Programmers and non-programmers alike can now create enterprise-grade application software through graphical user interfaces (GUIs) and configuration instead of traditional computer programming.

    It is increasingly clear that these tools will form the prevailing wind of innovation, filling the sails of digital transformation for years to come—some have already called it the most disruptive trend of 2021. Yet many industries are only just beginning to realize the possibilities that no-code truly holds. Here are five of the industries that are benefiting most from the no-code revolution, and tips for how companies in each sector can continue to successfully implement no-code tools.

    1. Retail
    For years, online shopping was a convenience for many consumers. In 2020, it became a necessity.

    After a decade spent struggling to keep up with the rise of online conglomerates, the fate of retail industries was already questionable when the COVID-19 pandemic hit. Indeed, many of the businesses that first began to fail in the earliest days of the pandemic were retail giants who relied too heavily on their brick-and-mortar appeal. For brands that bit the dust, the “why” is no big secret: they failed to adopt new digital technologies and lost the loyalty of couch-bound customers.

    With no-code tools, the transition from “customer-friendly storefront” to “customer-friendly front end” is becoming quicker and easier than ever before. By allowing retailers to develop brand-tailored digital storefronts and progressive web apps that are as easy to design as they are to use, these tools will undoubtedly be one of the keys to success as the retail industry fights through the pandemic and looks toward a sustainable future.

    2. Insurance
    As with many legacy industries, insurance was long caught in the shadow of flashy innovators from the tech sector. But the push for transformation in insurance came not a moment too soon—not only did the year leading up to the pandemic see insurance leaders set their sights on digital innovation, but it was no-code tools that played a crucial role in leading the charge toward change.

    By allowing traditionally slow-moving enterprises to operate with startup agility, no-code tools are giving legacy insurance leaders in previously sheltered markets the edge they need to compete with digital-first newcomers.Today’s consumers increasingly expect a seamless digital user experience with everything from social media to gaming to insurance. With no-code tools, these expectations can be met without the need for high-level programmers or IT professionals.

    As they look toward the future, insurers who implement no-code platforms will be able to spend more time focusing on the quality of their products and less time losing customers due to outdated tech, all while cutting costs and simplifying operations at every level of their organization.

    3. Banking, Fintech and Payments
    Banking, another industry rife with legacy enterprises, has faced many of the same hurdles as its insurance counterpart, and it is for many of the same reasons that no-code development tools have extensive potential in the ever-shifting landscape of banking and its adjacent sectors.

    Mobile banking applications have already changed the way that everyday people think about, track and interact with their money. In a digital era where remote functionality is as urgent as it is practical, no-code tools can provide financial enterprises of any size with the opportunity to build, maintain and update consumer-facing platforms that meet customer standards, offer cross-platform integration and uphold necessary private data security.

    4. Health Care
    The COVID-19 pandemic has been a powerful accelerant for a diverse array of health care technologies, fueling rapid growth in fields like telemedicine and remote patient monitoring. As health systems continue harnessing technology to become more efficient and to improve patient outcomes, no-code tools can provide innovative solutions to multiple problems through the entire process of healthcare and treatment.

    Calendaring and scheduling platforms that make it easier for patients to arrange appointments, and easier for providers to keep track of them, can be developed and curated without writing a single line of code. No-code platforms are also one of the simplest ways that health care practitioners can offer user-friendly virtual visits, saving time for patients and providers alike, and minimizing unnecessary trips to and from germ-filled waiting rooms. Additionally, the ability of no-code platforms to turn high-level back-end data functionality into a widely accessible tool will make it easier than ever for health care organizations to log patient data securely and swiftly, which can ultimately be leveraged to track illnesses and find treatments, fast.

    With the ease of no-code development, health care professionals can spend less time addressing technical difficulties and more time addressing their patients.

    5. Manufacturing
    Manufacturing leaders have already expressed a keen understanding of the need for no-code solutions.

    Manufacturing Execution Systems (MES) have long been tasked with coordinating, executing and tracking the processes at a given factory or plant, but the rigidity that makes MES so useful for IT components of the manufacturing process also makes it difficult to use for shop floor personnel.

    Compared to MES, no-code platforms are cheaper to customize, quicker to implement and easier to update in accordance with changing operational needs. As manufacturers are increasingly expected to produce new, customized products with increasing speed and frequency, the need for no-code solutions will go from being a tech trend to an industry necessity.

    Unlike many past disruptive trends, which have often been characterized by their uniqueness, the rise of no-code is making innovation easier and more accessible across the board. While the industries listed above—retail, insurance, banking, health care and manufacturing—are each particularly well-poised to benefit from the no-code revolution, these five sectors mark only the beginning of what is to come.

    The development capabilities of no-code platforms will only continue to grow in the coming years. So, too, will the reach of these innovative tools.