devopsy.kinsta.cloud

Category: Enterprise DevOps

  • What Is User Acceptance Testing and Why Is it so Important?

    What Is User Acceptance Testing and Why Is it so Important?

    Anyone involved in software development knows how important it is to ensure a positive end-user experience. One way to do that is through the use of user acceptance testing (UAT). 

    UAT is one of the types of testing that you can execute as part of your overall quality assurance process. 

    Source

    It’s essential in helping you determine if your product is market-ready and if it can perform effectively when used by real end-users. 

    UAT helps you avoid implementing software, iterations, upgrades, or customizations that are filled with pesky bugs that can destroy the user experience and render your software unusable (not to mention the damage done to your business’s reputation). 

    When the stakes are so high, it’s clear to see why businesses need a process such as this. In this article, we take a look at user acceptance testing, why it’s so important, and six ways brands can use it to their benefit.

    What is User Acceptance Testing (UAT)?

    User acceptance testing (sometimes known as end-user testing, user acceptability testing or beta testing) is the last step in the entire testing process of any software.

    In product management terminology, acceptance testing takes place as beta testing whereby a small group of early adopters test out the platform and provide user feedback to let you know if the solution meets user expectations and business requirements. 

    It’s done after the system, functionality and all other tests are completed and before the product is launched. 

    The image below shows some of the quality assurance (QA) tests that precede user acceptance testing. 

    Source 

    As you can see from the image, as development work moves forward, UAT progresses from unit testing to integration testing, then system testing and, finally, acceptance testing.

    This final stage is arguably the most crucial element of software development because it ensures a positive end-user experience. 

    As its name implies, it helps you determine if your platform will be accepted by end-users. 

    Testers (end users) work from a checklist of expected outcomes from the test platform and then record what happens when they attempt to execute the different tasks, such as:

    • Logging into the user’s account
    • Placing an item into a shopping cart
    • Checking out 
    • Buying multiple items that qualify for free shipping

    … and so on. 

    If the expected outcomes are achieved when each task is executed, then the software is approved for release. If not, it’s sent back to the developers. 

    This testing process requires collaboration between different stakeholders including project sponsors, business owners, analysts, QA teams and developers. 

    Why is UAT Important to Software Development?

    Although there are many ways projects can benefit from UAT (some of which we’ll look at below), this process is often overlooked by developers. 

    Many see it as a time-consuming and unnecessary process, which is unfortunate because acceptance testing can actually help improve software quality as well as the overall acceptance rate of any newly implemented software. 

    Think about it: You would never drive an untested car, would you? Similarly, businesses should not take risks by implementing software that has not been tested. 

    Considering the time and money you stand to save by ensuring that your software works in accordance with a predetermined test plan, it’s clear that this is something developers need to take more seriously. 

    In fact, far from being the time drain that many developers think it is, UAT can actually gain you a lot of time. How? By preventing unnecessary waste. 

    And far from being a one-off when you come to the end of the project, user acceptance testing extends beyond business application projects because of factors like additional phases, hotfixes, releases/further modifications or customizations and upgrades. 

    Take a look: 

    • Additional Phases: If you choose to roll out at this stage or upgrade an existing application in a phased approach, each phase can have different types of users, different companies (for parent companies, acquisitions, mergers, etc.), additional locations, etc., and you’ll need to plan and conduct separate additional acceptance tests for each individual phase.
    • Hot Fixes: Bug reporting or developer testing during regular day-to-day operations can lead to hotfixes. However, these bug fixes will have to be tested by end-users to make sure that they actually solve the problems originally reported.
    • Further Modifications: Software creators regularly release updates, including limited distribution releases (LTR) and general distribution releases (GDR). LTR releases usually fix issues in a specific problem area, whereas GDR releases are typically heavily tested before release. Both need to be tested to ensure that they fit users’ real-life scenarios so you can achieve your business objectives.
    • Upgrades: Everyone wants to offer their customers the best and most advanced experience. That’s why, for the most part, brands update software regularly to follow industry trends and keep up with the latest innovative technology. Regardless of the upgrade approach you take, whether it’s a little or a lot of customization, it’s crucial that your plan is completed according to business requirements. This will help ensure that the project’s end result is in line with the original business requirements.
    • Privacy Policy Updates: Many end-users may enjoy the overall functionality of the software, but they may desire increased integrations with other platforms or the ability to use a different payment method than that which is currently accepted. While these upgrades and modifications may be easily completed, you may need to alter the information you input into privacy policy generators to ensure that your users legally consent to any new use of their data or access to it by third parties.

    Now that you understand what UAT is and why it’s so important, let’s look at some of the benefits of user acceptance testing to give you a better idea of all the different ways you can leverage it in your own business. 

    Benefits of User Acceptance Testing

    At its core, user acceptance testing will be pivotal in the successful launch and/or maintenance of any type of online platform, whether it’s a simple mobile app or something more complex, such as an eCommerce website. 

    If the test object doesn’t work as desired, the faulty business functions are documented and the item is sent back to developers for repair. 

    Going through this final check ensures that your platform is well-built and performs as expected and that users accept the finished product. 

    Listed below is a summary of the top benefits of UAT: 

    • Benefit: The UAT process allows you to demonstrate that the software’s required functions are operating in a way that’s suited to real-world use and circumstances. As such, acceptance testing focuses on software performance and user behavior to ensure that interactions between the test software’s functionality and the end user’s thought process are aligned. 
    • Benefit: Furthermore, you’ll be getting a much better piece of software because it will be tested and verified by the same people who will be working with it every day. You’ll get optimal opportunities to quickly identify and repair any broken features. So, it’s easy to see how the time you invest in these beta testing cycles will lead to significant improvements in the quality of your software.
    • Benefit: Not only that, but the quality review provided by UAT is also a great way for stakeholders to secure a healthy return on investment (ROI) out of projects. Also, it keeps maintenance costs low and it’s cheaper and faster to fix usability/functionality issues early on.
    • Benefit: You’ll also be able to ensure that your software integrates with third-party platforms including various website builders, email marketing software, project management tools, communication apps and everything else you or your end-users might need to effectively use the software. If your software is supposed to allow for social media sharing, for example, you want to ensure that end-users are able to easily share without going through multiple steps that decrease an otherwise positive experience with the software.

    As you can see, user acceptance testing is vital to the successful deployment of new business applications and software enhancements, as well as to ensure organizational efficiency and success.

    The process helps you to mitigate risk and boost the ROI of your project. But most importantly, UAT ensures that your customers don’t end up being acceptance testers by default, which would have a negative impact effect on your business.

    6 Ways to Use UAT

    Here are six ways you can use this process to achieve better outcomes.

    1. Use user acceptance testing for internal development.
    2. Use the testing process to review new features.
    3. Invite users to take part in the tests to help them become more invested in the brand and become brand ambassadors.
    4. Use beta tests as a premium feature to convert subscribers to higher tier packages, increasing sales for the company.
    5. Share information about UAT and its results on social media platforms, email and other channels as part of your digital marketing campaigns.

    These are just a few of the different ways your organization can benefit from UAT far beyond the initial goal of the testing process. 

    And remember, it’s all about the users. 

    UAT isn’t just another testing technique. This test puts the user at the center of the discussion to answer questions such as:

    • Are users able to use the software without error(s)?
    • Does the solution meet promised specs? Does it behave in an expected way?
    • Does the software continue to work when users take unexpected actions?

    …and so on. 

    Whether the platform is constructed in-house or by a third-party company, all solutions must go through user acceptance testing because your users are the ultimate audience who will pay for your solutions. For this reason, it’s worth taking the time to ensure that your software solution meets both user expectations and business requirements.

    Planning and Managing the UAT Process

    The key to a successful UAT testing process is to understand the needs of your target users and their expected behavior. This way, you’ll be able to develop defined acceptance criteria so you can come up with efficient tests to complete the testing process fast. 

    Also, since the goal is to assess the market readiness of the product, it’s important to record all evidence and track progress with the dev team as well as report to stakeholders so everyone is on the same page. 

    With that said, here are five steps to help you plan and manage the user testing process: 

    Step One: Planning. The user acceptance testing strategy mainly includes a time frame outlined during the planning step.

    Step Two: Designing Test Cases. Test cases cover the core functional frameworks of the platform in real-world usage. When designing test cases, you need to do the following: 

    • Determine the needs of target users and stakeholders 
    • Design test cases according to the user journey and product specifications 
    • Summarize test runbook, acceptance criteria, etc. 
    • Prepare test data, e.g. registration, three days in use, one week in use, etc. 

    Step Three: Setting Up Your UAT Team. The acceptance testing team is comprised of real-world end-users or users who are not part of the development or testing phases to ensure objectivity. You should never use developers to test their own software as they may bring bias (albeit unintentionally) into the testing process. 

    Step Four: Executing and Documenting Test Cases. The UAT team executes the test cases, together with relevant random exploratory tests, after which all bugs are logged into the bug tracker along with steps to reproduce.

    Step Five: Bug Fixing. Once you’ve executed the test cases, you need to keep track of the tickets and user feedback. The development team can account for all the bugs found by the testers and start fixing bugs depending on severity. 

    Step Six: Confirm Fixes and Get Stakeholders to Sign Off. Once all UAT tests have been run and the results are in hand, the acceptance decision can be made. If all users are satisfied, then it’s a go. If not, it’s a no-go. 

    Last But Not Least

    UAT is the last stage in the software development life cycle. But, it’s also one of the most important things you can do to ensure the success of your software. Just keep in mind that for this process to be effective, it should be viewed as validation and not verification. Use your test procedures to validate functionality in both smaller scope (as a way to test functionality) and in a larger context (to simulate real-world processes) so you can get an end-user vision of your product which will ultimately help you increase the robustness and usability of your software.

    Are you ready to use UAT to get feedback on your software so you can increase end-user happiness? Share your thoughts below!

  • TechStrong Con: Open Source Software Community Needs Security Help

    TechStrong Con: Open Source Software Community Needs Security Help

    The only way to make significant improvements in the state of open source security is if more organizations that benefit from open source projects commit to making more resources available to achieve that goal.

    At the virtual TechStong Con event, executives on an Open Source and DevOps panel called for more contributions from enterprise IT organizations to ensure the integrity of open source software.

    Organizations of all sizes now benefit from open source software whether directly or indirectly. Those organizations have a responsibility to participate in the development of that software in any way they can, said Jeffrey Barnes, senior software engineer for Remote Operations, a provider of medical transcription services. “We need to give back to the community,” he said.

    Those efforts don’t necessarily have to involve contributing actual code, added Barnes. Many open source projects are in need of documentation and testing help because the number of actual maintainers of the project is relatively small, he noted.

    The challenge is that many enterprise IT organizations don’t understand how to participate in open source software development processes, noted Tom Sweet, CIO for Industrial Refrigeration Pros. An organization might download a piece of open source software and then extend it. Rather than continuing to maintain that branch on their own, organizations should contribute that code back to the project to reduce maintainers’ overall IT burden, Sweet said.

    “Many organizations are struggling to contribute back,” said Sweet. “It’s an evolution.”

    Organizations clearly need to make contributing code back to open source software projects a natural extension of their DevOps workflows. In the meantime, the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects.

    The core issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

    Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities.

    It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Many of them assume that open source projects are supported by IT vendors when, in reality, there are many projects that are dependent on the efforts of a small handful of developers volunteering their time and skills.

    Many organizations, of course, may soon decide not to employ open source software if it doesn’t have a critical mass of developers working on it. However, in an era where DevOps teams and developers routinely download software, enforcing those policies is going to be problematic. The best thing enterprise IT organizations can do is engage with the open source software community more rather than less.

  • Cloudflare Outage Outrage | Yet More FAA 5G Stupidity

    Cloudflare Outage Outrage | Yet More FAA 5G Stupidity

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

    This week: Cloudflare suffers another huge outage while the FAA and FCC still disagree over 5G/NR near airports. (more…)

  • Survey Shows Correlation Between Open Source, DevOps Skills Demand

    Survey Shows Correlation Between Open Source, DevOps Skills Demand

    A survey published this week by the Linux Foundation suggested enterprise IT organizations now prefer to hire IT professionals that have both open source software and DevOps experience.

    Conducted in collaboration with edX, a leading global online learning platform from 2U, Inc., the survey polled 1,672 open source professionals and 559 respondents with responsibility for hiring open source professionals. The results revealed there is also a high correlation between demand for that expertise and familiarity with DevOps.

    In terms of skills most sought, 69% of employers said they are looking for IT professionals that have cloud and container technology expertise followed by Linux (61%) and DevOps/GitOps/DevSecOps expertise (57%). Another 40% are looking for individuals with cybersecurity skills.

    More than three-quarters of the IT professionals (76%) surveyed currently work with Linux (76%), while 60% have worked with cloud/container technologies and 53% have DevOps/GitOps/DevSecOps experience. Well over three-quarters (79%) said it was either very important (44%) or extremely important (35%) to be familiar with DevOps.

    Clyde Seepersad, senior vice president and general manager for training and certifications at the Linux Foundation, said with all things being equal in terms of salary and benefits, more IT professionals preferred to work for organizations that are clearly viewed as open source software leaders. Organizations that want to recruit the best talent should make an effort to be seen as significant contributors to open source software projects to attract the best IT talent.

    Roughly half the respondents currently work for IT vendors, but the rest represented some type of end-user organization that typically consumes open source software. That distribution showed that demand for open source software expertise has now moved well beyond IT vendors that build commercial applications and IT platforms, he noted.

    Overall, the survey found 93% of employers struggling to find enough skilled talent, with nearly half of respondents (46%) planning to hire additional IT professionals with open source software expertise in the next six months. A full 86% said hiring IT professionals with open source software expertise was a priority. Well over two-thirds of employers (69%) said they are more likely to hire an open source professional with a certification. A total of 90% of employers said they will pay for employees to obtain certifications, with 58% reporting that open source IT professionals typically have higher salaries.

    A total of 81% of the open source software professionals surveyed also said they planned to add certifications this year. Nearly three-quarters of them (73%) also noted it would be easy for them to find a new job. About a third of those respondents either left or changed jobs in the last year, the survey revealed. Two-thirds of open source software professionals said a higher salary would deter them from leaving a job.

    More than three-quarters of IT professionals (77%) also noted they would benefit from additional cybersecurity training.

    However, only 43% of employers identified training as a means to close their current skills gaps. Another 41% said they hired consultants to fill these gaps. Only 16% of those respondents said they were willing to delay projects because of a skills gap.

    It’s clear that IT vendors and enterprise IT organizations are, in many ways, competing for the same talent. The challenge enterprise organizations face is making sure they have a high enough profile to be perceived as a place where IT professionals can make a meaningful open source software contribution.

  • At Some Point, We’ve Shifted Too Far Left

    At Some Point, We’ve Shifted Too Far Left

    Those of us involved in DevOps have a tendency to see the world with blinders on. It is rather easy to fall into the “If all you have is a hammer, everything looks like a nail” trap. We have used the phrase “shift left” with the attitude that this is the solution to every problem in IT.

    Just for clarity, it is not. That is as blunt and unambiguous a statement as I can make. DevOps is great and has helped in many areas, but it is not the only solution, and not every problem is a DevOps toolchain problem.

    In the end, much critical work in IT is not DevOps-related, nor can it be impacted by DevOps. I’ll mention two areas that are obvious and talk in-depth about one of them.

    First off, no matter how far down the Agile/DevOps trail you travel, the wagon you are riding in is separate and distinct from the DevOps process. If you have a data center, all that hardware is still, in the end, hardware that must be configured and managed. For the “But we’re 100% in the cloud!” crowd (who say that loudly and forcefully enough that I suspect they’re trying to convince themselves that this is a good thing)—in the end, you are still using a network and computers to connect. The massive work-from-home migration due to lockdowns made it abundantly clear that IT is needed to set up and support both. Some of the horror stories coming across ops and DevOps social media were … ugly. Employees don’t want to be—and should not need to be—IT specialists to get their job done.

    The other easy one is security. Yes, insert security into development and DevOps workflows. Yes, make operations staff more aware of security. Yes, automate security as much as possible because we’re chronically short of security staff. But, in the end, lots of security is external to DevOps. While Kubernetes security is absolutely DevOps, password management, for example, absolutely is not. And that’s just one of many, many examples.

    So I am going to ask (but not answer) the question: Where is the line? How far left is too far? The answer is yours to decide with regard to your organization and the tools/environment that exist in your organization. In a primarily cloud environment, the answer to this question is far different than in a primarily data center environment. It is rare that any organization be purely one or the other at this point in time, so there are similarities, but few exact solutions we can name.

    Security is akin to a cost center. It is actually insurance, but few orgs view it that way. And even if they did, it would not make much difference. Much as my father once declared that he and Mom were “insurance poor” and canceled half their policies, most orgs want to contain the costs of security whether they admit it or not. When ‘security merged into DevOps’ hits the ears of people trying to stretch budgets just as far as they can, bad things tend to happen.

    DevSecOps implements security where it should have been all along—at the development stage—but it does not replace other security, it just makes our apps more protected. There are cases where security testing hours are seriously reduced, but since testing in all forms is the first thing to go when staffing is tight, again, it is not replacing something that was happening—it is making it possible for us to do what we should have been doing all along.

    It doesn’t help that our toolchains have taken on lives of their own—at many organizations, staff are required to maintain them—because they, too, are apps that DevOps struggles to help. Once you’ve invested time and money in building that edifice, you want to use it as much as possible. So, many orgs want to shift left everything in IT, right into the toolchain octopus.

    You know your org better than anyone. You are the ones making it work day in and day out, in all of your environment’s glorious complexity. Start talking about what is too much; when adding a step in an already complex toolchain needs to be justified. Push back against everything needing to shift left (where appropriate, I’ll say again for clarity, DevOps has done amazing things for us, but too much of a good thing is our living nightmare and, historically, is tomorrow’s technical debt). Keep rocking it, and make sure you are rocking the right things in the right places.

     

  • Survey Uncovers Depth of Open Source Software Insecurity

    Survey Uncovers Depth of Open Source Software Insecurity

    A survey from Snyk and the Linux Foundation published today found that less than half of respondents (49%) work for organizations that have security policies in place for the use or development of open source software.

    The survey, which polled 550 software development professionals, was conducted by Snyk, a provider of tools for securing software, and the Linux Foundation. Just under a third (30%) of respondents without any policies in place also admitted that no one on their team is currently directly addressing open source security. A total of 41% said they didn’t have high confidence in their open source software security. Nevertheless, 59% of respondents said the open source software they deployed is somewhat or highly secure.

    Matt Jarvis, director of developer relations for Snyk, said many organizations are not aware of the degree to which open source software is now being targeted by cybercriminals looking to surreptitiously insert malware into widely used software projects. Those same organizations also lacked clarity about how open source software is constructed, he added.

    In many ways, the open source software community has now become a victim of its own success, noted Jarvis.

    Overall, the survey found the average application development project has 49 vulnerabilities and 80 direct dependencies on open source software. Only 18% of respondents said they are confident of the controls they have in place for their transitive dependencies. A full 40% of all vulnerabilities discovered were found in transitive dependencies.

    Only a third of respondents (33%) are using static application security testing (SAST) tools within a continuous integration process or software composition analysis (SCA) tools to discover those vulnerabilities, according to the survey. Overall, 44% reported they use some type of tool to analyze source code.

    In terms of additional capabilities, 59% said they would like to see more intelligence added to these tools, while 52% cited a need for more clearly defined cybersecurity best practices. Nearly half (49%) also wanted increased automation and tools for conducting security audits.

    The survey also found that fixing vulnerabilities in open source projects takes 19% longer than in proprietary projects.
    Among organizations that do have security policies in place, 80% vested responsibility with the security team. Only 40% of organizations without such policies did the same, according to the survey.

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. Developers today routinely reuse open source software. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

    Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities. Hopefully, following an executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead.

  • TechStrong Con: Downturn Brings Additional Sense of DevOps Urgency

    TechStrong Con: Downturn Brings Additional Sense of DevOps Urgency

    Regardless of whether the overall economy is experiencing a correction or is on the cusp of a recession, organizations are going to prioritize some projects over others as resources become more constrained.

    During the “DevOps: Has the Bubble Burst?” panel made up of DevOps executives and investors from venture capital firms that kicked off the virtual TechStrong Con event today, panelists said organizations will need to continue to invest in DevOps automation and cybersecurity to ensure their long-term survival.

    However, the number of IT projects that organizations will be able to simultaneously invest in is likely to decline, said Chenxi Wang, general partner for Rain Capital. “We are starting to see a slowdown of projects, for sure,” she said.

    Fundamentally, organizations will need to decide not so much whether they will modernize legacy monolithic applications but rather at what rate. More than 70% of organizations’ codebases are still based on legacy monolithic architectures, noted Wang.

    No one knows for sure how long the current economic contraction might last, but, as in any downturn, organizations will seek to conserve cash, said JFrog CEO Shlomi Ben Haim. DevOps initiatives will continue to be prioritized because otherwise, organizations risk falling far enough behind that they may not be able to ever recover, he added. “DevOps is in a good place,” said Ben Haim.

    In fact, thus far many DevOps companies have yet to see a decline in demand because organizations are investing in automation to reduce their technical debt costs, noted Thomas Krane, managing director for Insight Partners. “It’s a matter of life or death,” he said.

    At the same time, Krane said organizations might want to take a hard look at the profitability of the vendors they are counting on to drive that innovation. Vendors that have been counting on venture capital funding to maintain operations may soon find that money much harder to come by as capital becomes scarce, he noted.

    The core issue will become how quickly returns on investment (ROI) are generated, added Incredibuild CEO Tami Mazel Shachar. “There is going to be a lot more focus on ROI,” she said.

    In the meantime, the debate over what constitutes DevOps continues. Some narrowly define DevOps as a set of development activities that revolve around continuous integration/continuous delivery (CI/CD) platforms. Others definitions of DevOps include everything from application testing to observability and application security. No matter how big the proverbial DevOps tent is defined to be, however, the number of organizations that are embracing DevOps—and now DevSecOps—workflows more deeply only continues to increase.

    The challenge is focusing those efforts on the projects that deliver the most value for the business in the face of executive uncertainty about the future. Of course, nothing quite focuses the mind like an impending crisis; for better or worse, it will require more organizations to honestly assess their current capabilities.

  • Supergraph: One GraphQL Schema to Rule Them All

    Supergraph: One GraphQL Schema to Rule Them All

    GraphQL has been garnering much interest as a way to seamlessly interact with backend services. The query language is a boon for frontend developers, too, as it conveniently allows you to fetch the specific fields you require, thus eliminating the potential overfetching or underfetching concerns of REST APIs. And as GraphQL adoption matures within organizations, there is increasing interest (and investment) in how enterprises can use GraphQL to securely unify their growing catalog of disparate microservices and APIs.

    Using GraphQL as a meta layer could help unite many disparate systems under a single unified schema. This would enable the age-old promise of composability, in which software building blocks are seamlessly pulled together to assemble applications and unique experiences for different client types. However, managing GraphQL at scale can become tricky. And when a schema gets really large, it then may require a schema of its own! This is where the concept of the supergraph comes in.

    I recently met with Geoff Schmidt, Apollo GraphQL CEO, to discover what a supergraph is and how it may help platforms aggregate their backend microservices. According to Schmidt, “Developers want this composition layer for one abstract view of all their services.” Below, we’ll explore the concept of the supergraph and look at some new open source components that may help you enable GraphQL-based composability in your organization.

    Microservices Enable Composability

    First off, what do we mean by composability? Well, composable architecture is intrinsically linked with microservices. You can think of each microservice as a single lego piece that makes up one aspect of an application. For example, Uber uses 4,000 microservices to power its backend. These services span from maps, currency conversions, driver reviews, payments and other components. When combined, they ultimately create the convenience and the sleek user experience that is Uber.

    Historically, software developers were overseeing larger monolithic applications in which a single client was interconnected to a web server, Schmidt explained. On the other hand, microservices tend to be more domain-specific and used in tandem with other microservices. They’re also typically easier to iterate on and faster to ship when compared to monolithic codebases.

    The Need for Aggregation

    As a result of the microservices age, applications typically pull in far more data from various sources. For example, a banking application might loop in a mortgage service, investment service and other data sources to display a combined net worth on a screen. This explosion in microservices has created a “polygon environment” spanning databases and APIs, increasing service complexity, said Schmidt.

    Nowadays, many third-party components must be combined to render an experience. However, supporting this composability can be challenging for developers and backend API teams—not to mention that handwriting a backend-for-frontend could be burdensome. “App developers are slowed down by the need to integrate or compose these backend services,” said Schmidt. “Developers need a way to put all those pieces back together.”

    What is Supergraph?

    Supergraph can be thought of as a graph of graphs. The vision is to have one GraphQL schema and one ingress port to oversee many services. Creating a supergraph is becoming more accessible, too, as more open source projects emerge to enable this paradigm. For example, Apollo recently open sourced some components that can help to build and operate a supergraph. These include Federation, which helps to create a data graph across multiple services, and the Apollo Router, a tool written in Rust that decides how to route queries. Apollo has also open sourced a supergraph demo along with other resources.

    A supergraph architecture is already powering Expedia, Walmart, Netflix, Paypal, the New York Times and other large environments, said Schmidt. For example, Expedia has used a supergraph to combine flights, rental cars and other microservices to create integrated experiences. Hivee, an upstart modern supermarket chain, also uses a supergraph to unite its investment into APIs.

    According to Schmidt, the fundamental benefit is that less time is spent writing integration code which means faster development speed and the ability to quickly pivot your business. “It allows you to change business quickly to meet the needs of your customers.” A supergraph could also enable greater visibility into your API estate, making auditing easier.

    A key benefit of the above components is that they already have a proven track record running at a commercial scale. But outside of the Apollo projects, other groups are attempting to codify a similar GraphQL schema aggregation concept, as well. For example, WunderGraph utilizes GraphQL within a “virtual graph” that acts as a common language to call various underlying APIs.

    Repercussions of ‘One Graph to Rule Them All’

    Schmidt said the hope is that, at the end of the day, this abstraction can contribute to “making the world a little more human-centric.” This is because GraphQL can enable less rigid apps that conform to unique user tastes. But a robust composition layer will be necessary to allow such reconfigurations.

    Of course, as I’ve covered previously, there are significant security hurdles to address when supplying so much power to a single entryway. Increased GraphQL reliance will require forethought into new potential security risks, such as schema introspection and object-level authorization control.

    According to Schmidt, a GraphQL composition layer presents an opportunity to enforce security controls. He defines these as contracts that create access rules for a particular set of users. By declaratively managing GraphQL security, a development team, in essence, could expose a subgraph of the supergraph for a partner to consume. The graph could even be segmented for internal teams.

    A central point of ingress will require authorization rules to protect user privacy and avoid breaking the rule of least privilege. Schmidt also advocates for backend schemas to be built for app developers who understand their needs, instead of precisely mapping logic to business models.

    Supergraph: A Graph of Graphs

    Software is becoming more modular, which has resulted in an explosion of unique microservices and APIs. And we’re now at another tipping point in how software architecture is divided and combined, said Schmidt. He now sees GraphQL as a prime opportunity to create software architectures that call multiple backend services with a single GraphQL query.

    “GraphQL is the composition layer you need to build modern applications,” said Schmidt. “We’re super excited about this. Users have shown that GraphQL is the future. Supergraph is such a powerful technology, and we’re excited to bring this to everybody.”

  • Armory Aims to Turn Continuous Delivery Into a Service

    Armory Aims to Turn Continuous Delivery Into a Service

    Armory this week made generally available a continuous delivery-as-a-service (CDaaS) offering that promises to make it simpler for a much wider range of organizations to programmatically deploy applications.

    The Armory Continuous Deployment-as-a-Service platform has been available in beta since March. It differs from Armory’s existing open source Spinnaker continuous delivery (CD) platform in that it is based on a proprietary declarative platform that is designed to integrate with third-party continuous integration platforms.

    Armory CEO Jim Douglas said the goal is to meet organizations that have invested in CI where they are versus requiring them to rip and replace their entire DevOps platform. The company is still committed to providing a curated instance of Spinnaker, but it’s become apparent there are many organizations that want to experience the benefits of a more opinionated CD platform that is more accessible via a cloud service, he added.

    The Armory Continuous Deployment-as-a-Service offering applies many of the best practices that have emerged for the Spinnaker CD platform without requiring organizations to have a dedicated team in place to just manage the CD platform, noted Douglas. IT teams can start using the service to deploy applications in less than 30 minutes, he noted.

    The first edition of Armory Continuous Deployment-as-a-Service is optimized for deploying microservices-based applications on Kubernetes clusters, but Armory will soon extend the reach of the service to platforms running monolithic applications, said Douglas. The company also plans to make available an on-premises edition, he added.

    In either scenario, IT teams will be able to engage in everything from canary testing of deployments to automatic rollbacks in the event an application fails, said Douglas.

    The number of organizations that routinely make use of a CD platform is still relatively small. Historically, each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise.

    Douglas said that as more IT teams start to build and deploy microservices-based applications, it’s only a matter of time before CD becomes a more distinct IT discipline. The challenge is enabling IT organizations to achieve that goal without necessarily having to hire a small army of site reliability engineers (SREs). There will still be plenty of DevOps teams that will prefer to deploy Spinnaker, but Douglas said there will also be plenty of instances where a less complex approach to CD will suffice.

    It’s hard to say whether there might soon be varying levels of DevOps platform services that organizations might invoke depending on the complexity of the project and their own internal cultural preferences. However, as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. There may be many ways to achieve that goal, but if history is any indication, the path of least resistance is likely to be via the cloud.

  • Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

    Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

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

    This week: Warren Buffett asks too much for wind energy, it’s “completely ridiculous” to say Google’s chatbot LaMDA is sentient, and Microsoft finally kills Internet Explorer. (more…)