devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Testim Adds SDK to AI-Based Testing Platform

    Testim Adds SDK to AI-Based Testing Platform

    Testim this week launched a beta release of a software development kit (SDK) consisting for a set of JavaScript application programming interfaces (APIs) that will enable DevOps teams to build tests that leverage machine learning algorithms from within their integrated development environment (IDE).

    Company CEO Oren Rubin said the Testim Development Kit makes it possible to call capabilities such as the ability to record user interface interactions via an application programming interface (API).

    The Testim approach to applying artificial intelligence (AI) testing differs from rivals in that Testim allows DevOps teams to fully inspect how algorithms construct a test, he noted. DevOps teams can also customize those algorithms to fit their own requirements, which is critical when it comes time for DevOps to explain how tests were conducted as part of a compliance audit.

    Testim will continue to provide access to its platform via a graphical user interface, but with the edition of the SDK, Rubin said his company expects to see an increase in the number of DevOps teams that will incorporate Testim within the context of continuous development/continuous deployment (CI/CD). Once that occurs, the number of tests those teams will be willing to run against software before it’s deployed in a production environment should also increase, especially as more developers leverage APIs to create their own tests, Rubin said. That doesn’t eliminate the need for another set of eyes to test an application, but it should reduce the number of common errors made before any piece of code is tested by someone else on the DevOps team.

    One of the most time-consuming elements of any DevOps process is the time it takes to create tests for each application. The Testim platform employs machine learning algorithms to discover the entire application environment and then begin creating appropriate tests. As DevOps teams modify those tests, the Testim platform continues to learn how to build tests the way the DevOps team prefers.

    The Testim platform doesn’t eliminate the need for testing expertise on the DevOps team, but it does enable organizations to scale their testing processes by augmenting whatever testing expertise they have on hand to reduce bottlenecks and improve overall software quality. Those algorithms also provide the added benefit of never taking a day off or quitting to take a more lucrative position elsewhere.

    When it comes to AI, there is naturally a lot of fear and loathing. On the one hand, IT professionals become concerned AI will replace them. On the other hand, they are often disappointed when machine learning algorithms don’t instantly automate a process to their satisfaction. It takes a significant amount of time for algorithms to learn how any IT environment operates, with each update to that environment requiring those algorithms to discover new functions. At this juncture, it’s not a question of whether AI will play a role in DevOps processes, but rather to what degree. Given the repetitive nature of testing, Testim is betting application testing will prove to be an area that lends itself to AI sooner than later.

    — Mike Vizard

  • The Power of Embedded Analytics and the Build Versus Buy Dilemma

    The Power of Embedded Analytics and the Build Versus Buy Dilemma

    Embedded analytics are a powerful tool for adding value and stickiness to your desktop and mobile apps. Many app developers are providing these features as standard in their tools. But should independent software vendors (ISVs), systems integrators (SIs) or companies building internal apps build analytics tools in-house, or should they buy them from specialist providers?

    There are many considerations to the buy or build dilemma. One reason many developers want to build in-house is the limitation of support services from embedded analytics vendors. Although most providers offer support services, these are not normally included in the price of the package, and are offered at an additional cost. However, in the majority of cases, such support services are in fact effectively a requirement to ensure the visualization is tailored to the use case and look and feel of the app.

    A second consideration is cost. Standard price entry points for embedded analytics can start at $30K to $75K per year. However, behind the upfront pricing structure, there are often multiple levels of service, as well as limits on usage and number of applications the embedded analytics can be used in. This can make pricing far less predictable.

    Creating analytics features in-house may be the best option when working on smaller projects with limited sets of requirements—especially if your development team has a relevant skill set and previous experience developing embedded analytics and data visualizations.

    Lastly, one of the most convincing arguments for building in-house is that product managers remain fully in control over every aspect of their application, not just its functionality but the look and feel as well. By keeping all aspects of development in-house, product teams can control branding, user experience and functionality. The loss of this control is one of the main disadvantages of buying.

    On the other hand, there are many benefits to buying rather than building. The main disadvantage of building in-house is that developers have to switch their focus away from working on the core product to create complex embedded analytics features. Buying saves time and money over training a development team that may lack previous embedded analytics experience and eliminates the need for training where internal resources are simply not available.

    There is also a significant cost associated with building embedded analytics, which on average takes seven months to complete. The estimated average in-house cost can run as high as $350k (based on average U.S. salaries). This includes: four software developers for seven months, one QA professional for seven months, two UX/UI designers for six months and one data scientist for one month.

    Your in-house team is generally responsible for supporting anything built in-house. With the buy option, support is provided by the third party via the cloud and ISVs will not have to allocate resources to fixing issues if and when they occur. As much as 90% of the cost of software during its lifetime is tied to keeping it up and running. Maintenance costs can be significant.

    The time it takes to bring a product to market is another consideration. With average build-it-yourself times taking seven months or more, many product teams decide to buy a bolt-on analytics solution due to the need to release a product as quickly as possible. In a fiercely competitive SaaS market, and with CEOs demanding quick turnaround, buying a pre-built, off-the-shelf solution drastically reduces your time to market.

    Making a final decision on whether to buy or build is a complex task. But in the end, ask yourself:

    • Can my team develop powerful analytics in-house or do I need a specialist? Building analytics tools can be a drain on time and internal resources, and the backend powering even a simple dashboard can be slow and expensive to build from scratch. Plus, you need the resources to maintain it.
    • How does the vendor’s pricing model stack up against my budget? You shouldn’t really be paying any more than what it would cost you to simply build the visualization in-house, so an affordable vendor is essential. However, too often, overly complex pricing structures from vendors result in unpredictable costs, making ROI hard to judge.
    • Has the company received awards for its work? Are they well established and respected in the community? Third-party review sites are helpful here.
    • How much do you trust the vendor? If you are collecting sensitive data, you want to be sure that the vendor isn’t also collecting that information covertly and selling it.

    As more organizations realize just how important understanding their data is, embedded analytics have become the key to harnessing that power. Whether you decide to allocate internal resources or hire a vendor, including powerful embedded analytics and visualizations is virtually a must since it helps you differentiate your app and keep users engaged.

    — Casey McGuigan

  • How Organizations Benefit from AWS App Patterns

    How Organizations Benefit from AWS App Patterns

    As a startup, an organization thrives by breaking rules, challenging the status quo and standing for all that is against the norm. The same rules don’t apply once the same organization grows, matures, becomes popular, gains a long list of clients and expands to a global footprint. With scale and growth comes the need for reliability, consistency, being able to deliver the same level of service to all customers and keeping promises made to customers. At this stage, application patterns become indispensable to an organization’s day-to-day functioning.

    Support of the Application Now and Long-Term

    Mid- to large-size organizations typically deal with numerous internal-only applications and external vendor applications. These applications are changed and updated regularly. To support the applications’ needs, and effectively manage them, organizations need a change management system in place.

    A service such as AWS Config helps to audit AWS services that power applications so there’s increased visibility. It tracks changes made by users and applications, and presents a clear picture of how these changes impact AWS resources.

    Enabling Shift-Left Without Additional Overhead

    DevOps bring together Dev, QA and Ops into smaller, cross-functional teams. The goal is to break down silos between teams, facilitate collaboration and drive better results faster. Accordingly, shift-left is a tactic used to encourage QA and Ops teams to play a more pivotal role in the initial Dev stages of the pipeline.

    The benefits are many. QA brings their experience of testing the application to its limits and informs about what’s feasible to implement. Ops chimes in with concerns and things to watch for once deployed. While shift-left is great from a team standpoint, it can meet with hurdles and can fail if communication patterns are random, and ownership of each step is not clearly defined.

    Application patterns encourage systematizing this collaboration between teams. Patterns help to define the type of infrastructure to be used, their configuration and the kind of tools that fit in with the team’s requirements. Application patterns guide decisions and help to make the right choices, and sometimes compromises, at every step.

    Supporting the Advancements in Open-Source Without Fear of Tool Attrition

    There is an explosion of open source tools today. If DevOps teams are attracted to the next shiny new open source tool, they’ll soon find themselves overwhelmed with tools they don’t use and that slow them down.

    Open source tools evolve quickly, and their popularity rises and falls with the times. One look at the open source monitoring space will show you that older tools such as Nagios and Zabbix are now becoming less relevant, and modern container-aware monitoring tools such as Prometheus are taking their place.

    AWS supports the use of the top open source tools; for example, Elasticsearch. The AWS Elasticsearch service integrates seamlessly with Kibana for visualization and delivers the ELK stack without the maintenance.

    Application patterns enable you to define a strategy for tool adoption. You may find the best open source tool in the world, but what’s the point if you can’t use it in your toolchain, or if it slows down the pace of operations? The popular DevOps mantra of people, processes and then tools holds true here.

    Value Stream Management

    Value stream mapping is about visualizing the flow of value from an organization to its customers. In simple words, it’s about taking stock of what you have to offer to customers and monitoring how your offerings change over time.

    Value flows outward to customers, as well as internally between employees and systems. For example, in the context of DevOps, it helps to map the value of Ops to Dev and QA. As these teams are each other’s internal customers, knowing what the value stream is can help remove bottlenecks and drive greater efficiency.

    Building a Team and Culture First

    AWS is a great place to build team culture as it is expansive and includes services for pretty much anything you’ll ever need. You can find tools such as CodePipeline to quicken development pipelines, to make sure everyone on the team is informed of important changes using CloudWatch and SNS queues, and to automate common tasks with Lambda.

    Rather than jumping feet first into AWS and then figuring out how it all works, it pays to first define application patterns and team culture that will govern the way you use AWS. Patterns and culture are closely related. If culture is about the people, application patterns are about the infrastructure and technology stack being used by people.

    Conclusion

    Whether you’re yet to move to AWS or are already on board but not getting the most out of it, application patterns help evolve the way you manage applications in AWS. Application patterns help scale applications over the long term, they enable shift-left for DevOps teams without the friction of overhead. Application patterns make it possible to adopt the right open source tools and find success with them. By using application patterns you can visualize the entire process and drive great efficiency, and finally, they support great team culture within DevOps teams.

    DevOps teams that run their operations predominantly on AWS need not fly blind. Application patterns bring greater visibility, control, collaboration and ultimately value.

    This sponsored article was written on behalf of Eplexity.

    — Twain Taylor

  • Eficode Adds Analytics to Managed DevOps Service

    Eficode Adds Analytics to Managed DevOps Service

    Eficode has added an analytics module to a DevOps platform it makes available as a managed service.

    Tuomas Keränen, product manager for Eficode ROOT, said Eficode ROOT Insights provides different types of end users with access to an analytics module designed to make it easier to understand how changes to a software development project will impact delivery timetables. To make that capability more accessible throughout the organization, Eficode has created dashboards for specific types of end users such as project managers.

    Eficode has crafted a DevOps platform from various tools and platforms to create a toolchain based on best practices it has defined that the company then manages on behalf of end customers. Organizations can choose to have that DevOps platform hosted on-premises or in a public cloud. That approach frees organizations to devote more time and resources to building applications versus managing the DevOps platforms, said Keränen. Eficode ROOT Insights is provided as a complement software-as-a-service (SaaS) application.

    As DevOps continues to evolve, it’s apparent that an alternative approach that relies on external IT service providers to manage the underlying platforms is gaining traction. Many IT organizations simply don’t have the expertise required to build and maintain a DevOps platform. The trade-off is that the best practices are defined by the external service provider, which means the IT organization needs to bend its culture to align with those best practices.

    Another factor that potentially will push organizations toward managed DevOps services is analytics. As the amount of data that needs to be collected to drive analytics applications steadily increases, it becomes apparent that DevOps analytics applications are going to be invoked more easily as SaaS applications. Once an IT organization moves down that path, it’s not too long before the case is made for using the analytics platform to also host the DevOps platform. In addition, as machine learning algorithms and other forms of artificial intelligence (AI) are applied to DevOps, the volume of data required to drive an AI model may require an organization to rely more on external service providers to provide that expertise.

    It’s not at all clear how many organizations may prefer a managed service approach to DevOps. Many of the earlier adopters of DevOps have built custom workflows that are designed specifically to optimize their software development life cycle. However, the adoption of DevOps has been uneven at best. As managed DevOps services proliferate, the number of organizations that can effectively embrace DevOps should increase significantly.

    Of course, managing the tension between internal and external IT service providers is nothing new. However, given the complexity of DevOps processes, relying on a managed service requires a level of collaboration that is not easy to achieve. Just as importantly, once an organization decides to partner with a provider of a managed DevOps service, unraveling that relationship later may prove to be all but impossible.

    — Mike Vizard

  • Mario’s Adventures in Tekton Land

    Mario’s Adventures in Tekton Land

    Tekton is an open source, cloud-native CI/CD pipelines engine. The project has its roots in the Knative project, where about a year ago it started under the name “Knative Pipeline,” with the aim of providing an extension to build Knative’s own “source to image” service. About eight months ago the project was reborn as Tekton and it moved out of the Knative space to its own GitHub organization and it joined the newly formed CD Foundation with a new mission: becoming the common denominator for CI/CD in the cloud-native space. But how is Tekton going to achieve its new aspirations?

    For it to be successful, we wanted Tekton to be intuitive, reliable and easy to operate and maintain. This was discussed in the Tekton working group, and we thought it would be useful if we started using Tekton ourselves as part of our day-to-day jobs, using it to provide CI/CD services to the community.

    Diving into Tekton

    Tekton pipeline aims to provide a set of components used to create a full-fledged cloud-native CI/CD system on top of Kubernetes.

    The core project of Tekton (tektoncd/pipeline) defines a set of Kubernetes custom resources (CRD) as standard constructs for creating CI/CD pipelines. The following is a brief introduction to these CRDs:

    • Task: A sequence of commands (steps) that are run in separate containers in a pod.
    • Pipeline: A collection of tasks executed in a defined order.
    • PipelineResource: Inputs (e.g. git repo) and outputs (e.g. image registry) to a pipeline.
    • TaskRun: Runtime representation of an execution of a task.
    • PipelineRun: Runtime representation of an execution of a pipeline.

    Those pipeline building blocks can be reused, version controlled and curated in a catalog (tektoncd/catalog) that embeds best practices.

    In addition, the Tekton community works on providing more components:

    • Tekton Triggers (tektoncd/triggers) to be able to act upon events (for example: GitHub webhooks, CloudEvents and more).
    • Tekton CLI (tektoncd/cli), which provides a command-line interface focused on the Tekton APIs and features (like getting the logs of your run, starting pipelines and more).
    • Tekton Dashboard (tektoncd/dashboard) which provides a simple dashboard (à-la-kube-dashboard) to view pipelines and logs from your browser.

    Re-Plumbing Test Infrastructure

    We designed Tekton to be intuitive, reliable and easy to operate and maintain. We started using Tekton ourselves as part of our day-to-day job, using it to provide CI/CD services to the community. But we didn’t start from a blank canvas.

    Tekton inherited a few features from the Knative ecosystem, including the CI setup. This was great as it allowed the project to relatively easily kick-start its CI using tools shared with several other projects in the Kubernetes ecosystem (including Kubernetes itself)–a combination of Prow, Tide, Boskos, a few tools from k8s.io/test-infra and several bash scripts contribute to tasks such as running E2E integration test.

    Deployment of the various CI services is manual and the same is true about their configuration. Releases are crafted mostly manually. Since Tekton is made of several projects, we set up tektoncd/plumbing repository to host the shared CI/CD infrastructure: prow configuration, shared test scripts and tools, test docker images. Mario adventure started!

    Mario’s Adventures

    We started to work on what we are calling the Dogfooding project, which is basically using Tekton to build Tekton. And like a ball of wool and a cat, the more we thought about it, the more questions we had. How is Tekton going to integrate with the existing prow-based CI infrastructure? How are we going to test changes to the plumbing repo in isolation? How are we going to deploy the instance of Tekton used to run Tekton CI pipelines? How are we going to do all that with no disruption to our CI service?

    Testing code continuously is essential infrastructure, even more so for cloud-native software, and re-plumbing all at once could leave us without running water. We decided to proceed with baby steps, reducing the area of impact as much as possible and starting our journey tackling the release automation work first.

    Here is an excerpt of the work we did on this journey:

    1. Run our releases using Tekton. That was the initial work, using Tekton to at least release itself, even if it gets triggered manually.
    2. Integrating Tekton and Prow. Prow is able to create Tekton resources since April of this year (#11888 if you are curious), although it took a few iterations to be able to use it on our own CI.
    3. Looking at solutions without using Prow at all. This one was (and still is) the trickiest:
      • We needed something that is able to react based on events (from GitHub), this is where the tektoncd/triggers project comes into place.
      • Prow comes with a UI and tooling to capture and store logs. This piece is missing from the Tetkon project as of today. We do have the tektoncd/dashboard project but it’s early days, there is no support for authentication yet.

    Mario’s Adventures at KubeCon

    Mario’s adventures will continue at KubeCon in San Diego. If you’re attending the conference  and you’re curious to know more, come and listen to our talk, or watch it on the CNCF youtube channel after the conference.

    This article was co-authored by Andrea Frittoli is a developer advocate at IBM and an open source enthusiast. He is a contributor to the Tekton project and he has contributed to OpenStack for several years. He’s a strong advocate for transparency in open source. Andrea has previously been a speaker at FOSSASIA, FOSS Backstage, OpenStack summits, Open Source Summits, Devoxx Days and various meetups.

    — Vincent Demeester

  • The NVMF Boogie: How Kubernetes and NVMF Will Rock

    The NVMF Boogie: How Kubernetes and NVMF Will Rock

    I recently wrote a blog about how Kubernetes creates a global computing grid that delivers unprecedented compute flexibility. Then I wrote a blog about the importance of going fully Kubernetes-native. In today’s blog I would like to drill down into the role that the NVMe over Fabrics (NVMe-oF or just NVMF) standard will play in enabling Kubernetes infrastructure flexibility.

    What is NVMe?

    NVMe is a protocol that dictates how a CPU, moves memory via the PCI bus to a storage device. NVMe communicates over a set of rings (per CPU) where commands get submitted from any CPU to the underlying NVMe device. The design of NVMe eliminates intermediate layers between the CPU and the storage device. NVMe devices consist of a controller, queues, namespaces, namespace IDs and the actual storage media with some form of an interface.

    Storage media can be grouped into sections called namespaces with an ID. In the context of NVMF, namespaces provide a way to enforce access control for the disks/consumers. Namespaces are analogous to an OS partition, except the partitioning is done in hardware by the controller and not the OS (you can still have OS partitions on namespaces). Some NVMe namespaces might be hidden from a user (e.g. for security isolation). A controller connects to a port through queues and a namespace through its namespace ID. A controller is allowed to connect to multiple namespaces and a namespace is allowed to be controlled by multiple controllers (and thus also, multiple ports).

    Imagine smearing out this NVMe device across multiple computers and you get to the next important concept, a storage fabric.

    What is NVMF?

    When you put a network between the PCI bus and the storage device, you use NVMe over Fabric (aka NVMe-oF or simply NVMF). NVMF enables fast access between hosts and storage systems over a network. Compared to iSCSI, NVMF has much lower access latency, in practice adding only a small latency difference between local and remote storage. NVMF delivers a breakthrough in throughput and seek time relative to traditional device attached storage:

    Source: Samsung.

    This is possible because NVMF uses RDMA to efficiently access the memory of another computer without using the CPU or operating system of either. RDMA is a transport protocol that bypasses the kernel stack, offloading the workload to network hardware. This means the transport layer takes place in the RDMA NIC itself, so data is transferred directly to or from application memory without having to involve the normal OS-level network stack, achieving low latency with low CPU consumption.

    Of course, NVMF performance is gated by the networking infrastructure used, whether Ethernet, Infiniband or Fibre Channel. The November 2018 final ratification of the NVMe/TCP transport specification has accelerated adoption of NVMF because it allows storage fabrics to be deployed on standard network hardware.

    NVMF can be used with white label storage systems (JBOD), feature-rich block storage systems (SAN), and storage systems built with previous generation (SATA) devices. This means data centers can simultaneously leverage low latency devices while also using more traditional storage subsystems. NVMF also supports using storage class memory as a cache in the data center compute hierarchy.

    Why is NVMF Important?

    Think of NVMe as a replacement for SCSI, and NVMF as a replacement for iSCSI and iSER. NVMF has several distinguishing technical attributes that add up to huge performance scalability at the storage infrastructure layer:

    • Protocol Efficiency: The NVMe-oF protocol is designed specifically for efficient memory transfers at scale. Designed from the ground up for scalability, the NVMe-oF protocol dramatically reduces the internal locking needed to serialize I/O and improves the efficiency of interrupt handling. NVMe-oF also supports MSI-X and interrupt steering, which prevents bottlenecking at the CPU level and enables massive scalability as systems scale. Combined with the large number of cores in modern processors, NVMe-oF delivers massive parallelism to connected devices which increases I/O throughput and lowers I/O latency.
    • Command Set Efficiency: NVMe-oF has a streamlined and simple command set that uses less than half the number of CPU instructions to process an I/O request that SAS or SATA does, providing higher IOPS per CPU instruction cycle and lower I/O latency in the host software stack. NVMe-oF also supports enterprise features such as reservations and client features such as power management, extending the improved efficiency beyond just I/O. NVMEOF devices can approach DDR4 performance levels and, with SCM, become an integral component of the computing memory hierarchy.
    • Queue Parallelism: With 65,535 parallel queues, each with a queue depth of 65,535 entries, NVMe-oF supports massive parallelism. Every CPU has a private queue to communicate with a data device and is capable of achieving high speeds because there are no locks between queues that live on separate cores. Because each controller has its own set of queues per CPU, I/O throughput increases linearly with the number of available cores.
    • Integrated Security: NVMe-oF includes a tunneling protocol that provides security features produced by the Trusted Computing Group (TCG) and other related communities. Features planned for NVMe-oF devices and systems include simple access control, data at rest protection, crypto-erase, purge-level erase and others. Additional information on NVMe-oF security is available in the Trusted Computing Group and NVM Express Joint White Paper: TCG Storage, Opal and NVMe.

    NVMe-oF is designed not only to solve the limitations of scale-out storage, but also to lay the foundation for a storage fabric that dynamically shifts as workloads demand.

    What Makes NVMF Important to Kubernetes?

    Kubernetes applications implicitly need the infrastructure flexibility enabled by NVMF. NVMF and Kubernetes makes distributed computing within sites easier.

    The key point of my Kubernetes-native blog was “(Kubernetes-native) applications break apart into their constituent elements and can deploy and scale across the latency pyramid where they fit best. The elements dance across the infrastructure following their constituents in what I imagine as a containerized ‘ballet’ focused on delivering the best possible user experience at the lowest possible latencies.”

    However, multi-cloud, multi-site and edge deployments introduce significant additional complexity for organizations operating Kubernetes at (or beyond) enterprise scale. Business needs are pushing IT teams to move workloads between sites, clouds, WAN edge and rapidly be able to clone, burst and then destroy workloads anywhere around the world as needed. Yet Kubernetes deployment across multiple regions, sites, clouds and WAN edge remains problematic.

    OpenEBS is the solution for latency sensitive stateful Kubernetes workloads that need universal data agility. A NVMF-based disaggregated storage physical fabric mates perfectly with the disaggregated data agility software infrastructure offered by OpenEBS. NVMF allows data to physically float across a single storage fabric while OpenEBS allows stateful workloads to be loosely coupled across multiple storage infrastructures. And the OpenEBS MayaStor project natively integrates to NVMF to simplify the developer experience.

    Together, NVMF and OpenEBS become the dance floor for those Kubernetes-native application components to do their infrastructure-aware (and infrastructure-intelligent) ballet. Given its performance and scalability, however, perhaps this is better called the NVMF Boogie.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Charles Piercey

  • What Are AWS Application Patterns?

    What Are AWS Application Patterns?

    The cloud-native approach is not just about compute power and cloud services. A “set it and forget it” attitude won’t work with cloud native; there are far too many moving pieces and there is just way too much complexity. Instead, this approach requires constant testing, optimization and improvement. This is epitomized in the two key phrases of the DevOps methodology: continuous integration and continuous delivery.

    To make this a reality, however, it takes a strategic approach to defining application patterns that will govern the way in which cloud-native applications are built and shipped, rather than a one-off effort. Since AWS is the leading cloud provider, we should discuss which application patterns are relevant to the AWS platform. There are many aspects to consider when it comes to AWS application patterns, and we will cover them here.

    Operational Excellence

    The best starting point for application patterns is a commitment to operational excellence. Typically, the term “Ops” is used to identify the IT team, but in this case, operational excellence rests on the shoulders of Dev, QA and Ops teams. In cross-functional DevOps teams, every member should strive for operational excellence at every step–even in the smallest of tasks.

    In their white paper on operational excellence, AWS encourages its users to manage operations as code. This helps avoid human error, enables automation of complex processes and allows for quick and easy rollback when errors occur. Failure, according to AWS, is an opportunity for learning. They even advise performing “pre-mortems” that try to anticipate potential points of failure before a deployment.

    AWS Trusted Advisor is a useful tool that enables this type of accountability and shared responsibility within a team. It checks and reviews your new and existing AWS workloads looking for opportunities to save costs, improve performance, tighten security or follow best practices for scaling operations.

    Security

    Security is a pattern that is non-negotiable. The term “DevOps” has inspired another variation called DevSecOps that signifies this fact. Security operations take center stage when talking about DevOps.

    The interesting thing about DevSecOps is it actually results in more freedom, flexibility and trust across teams when done right. This is unlike traditional approaches to security which created silos, stifled creativity and slowed down innovation. Security is now a key piece of the puzzle, not an afterthought. AWS has many machine learning-based security solutions such as Macie which automatically identifies and secures personally identifiable information (PII).

    Along with this, configuring role-based access controls using AWS IAM is essential to have greater control over who or which applications access data and for how long. Access Control Lists govern access to data stored in AWS S3 buckets.

    The news is full of instances of data breaches due to weak security policies and access controls. Capital One is a recent example of a data breach that affected 100 million of its users. While security in the cloud is more complex than before, AWS has the necessary tools and systems in place. It’s up to organizations to implement a security strategy that prevents misuse of their data.

    Reliability

    Today, there is a low tolerance for downtime because of the potential loss of revenue. With the stakes so high, reliability is a pattern any application custodian would have high on their list of priorities. AWS has multiple reporting and health monitoring tools to keep you constantly on the pulse of your applications.

    Architectural patterns like microservices enable better resilience by decomposing monolithic applications into more manageable chunks called services. This “divide and conquer” approach leads to higher availability, which is critical for SaaS applications.

    Patterns like chaos engineering seek to intentionally kill random instances and services and force the DevOps team to figure out workarounds and backups for every scenario.

    Application Performance

    With the explosion of data, applications are always dealing with lots of data to transfer, store and process. An application’s performance depends on three factors: the backend data storage layer, the middleware components and the frontend.

    The backend data layer is the most critical component when it comes to performance. Choosing the right storage formats, database types, storage devices and organization patterns all contribute to the speed of data access. AWS has an amazing array of storage services, including S3, RedShift, Aurora and Glacier. AWS gives its users every type of storage solution, all of which should be considered to improve data management.

    AWS is devising new ways to query large datasets without bearing the load on your existing systems. RedShift Spectrum is one example of this. It is a great way to “minimize the need to scale Redshift with a new node, which can be expensive.” If you’d still rather not have to manage any RedShift clusters on your own AWS Athena is a great serverless alternative

    That gives you all the power you need to query large datasets in S3 without having to maintain any clusters of your own.

    This pay-per-use model is making its ways across the entire AWS stack with services such as ECS and Fargate offering completely serverless experiences when operating containers at scale. What started out with AWS Lambda is catching on fast, and many AWS services like the ones mentioned above enable serverless experiences with a focus on application performance.

    Cost Optimization

    When moving to the cloud, pricing is completely different. Rather than paying for perpetual licenses, you now pay a small fee for every small resource that you use. Though small on its own, you’ll soon realize that cloud costs can shoot up easily if you’re not paying close attention to your spending.

    Cost optimization is necessary as you scale operations in the cloud. Cost optimization includes looking for more efficient services, whether that’s within the same vendor platform or a different platform. At a minimum it may require a lift-and-shift approach to transition from expensive old infrastructure to inexpensive new alternatives. For example, shifting workloads from VMs to containers to serverless within the same platform can show great cost savings, since containers and serverless are generally more cost-effective than VMs.

    It pays to leverage the expertise of experts in this area. They should ideally be people who have spent years using AWS, understand Well-Architected best practices and have found ways to cut costs and derive more value from the same budget.

    Application Patterns Enable Extensibility

    Microservice applications adopt a pluggable architecture. This enables them to be easily integrated with external applications. Typically, API-based communication patterns are most common. AWS API Gateway is a service that manages API design for AWS applications. In some cases, an SDK is the better choice–for example, when you need more control over the developer experience and integrations. It’s important to know when to choose either option.

    Application Patterns Enable Portability

    Portability is the ability to move workloads across instances without interrupting their functioning. As instances change, the workloads which they support shouldn’t be affected. This is only possible if there is a clear separation layer between the workloads and the infrastructure that runs them.

    Application Patterns Enable Shift-Left

    The DevOps methodology is known to encourage a shift-left approach to software delivery. This means that not only Dev, but also QA and Ops contribute to the design and development stage of an application. This fosters deeper collaboration across teams and breaks down silos.

    A shift-right approach holds true as well. Shift-right means developers are responsible for the code they write. They are equal owners with operations teams for the resilience of the apps they build and also the bugs they introduce into the system. This practice of putting ownership and responsibility where it belongs is very healthy for a DevOps team.

    AWS facilitates pipeline management using tools such as CodePipeline, CodeCommit and CodeDeploy. They each perform similar but complementary roles and help build a CI/CD pipeline. They make it easy to get started with CI/CD within the AWS platform.

    For organizations further down the line in their cloud journey, AWS’ pipeline management tools may seem too simplistic for something like GitOps. Instead, they’d want to look outside AWS for tools such as Jenkins X or Weave Flux which are designed with GitOps automation in mind. Whether it’s the simple or advanced route, a pipeline brings great benefits over a manual development process.

    Conclusion

    Though tools enable the implementation of helpful application patterns, on their own, they are ineffective. Application patterns need a deliberate strategy and an approach for a start. Only after a strategy is in place, can you move to deciding which tools to use. With a strong strategy in place, any of the tools mentioned here can be swapped out for other better tools and the results will be the same. It’s important to not be distracted by the next shiny tool but keep a keen focus on the strategy for implementing AWS application patterns.

    As we’ve seen here, application patterns are diverse, but they all build upon each other. Without even one of these pillars, organizations would not be able to realize the goal of cloud-native applications. On the other hand, if they give careful thought to each of these application patterns, organizations would deliver cutting-edge applications that can only get better with the passing of time.

    This sponsored article was written on behalf of Eplexity.

    — Twain Taylor

  • DevOps at a Distance

    DevOps at a Distance

    How do you successfully follow DevOps practices when the two parts of your team are 5,000 miles (8,000km) and two time zones apart?

    Airwallex is a global fintech founded in Melbourne, Australia just four years ago. It is Australia’s fastest-growth tech unicorn with a valuation of over $1 billion thanks in part to investments from companies such as Tencent Holdings, Sequoia Capital, Square Peg, Horizon Ventures, DST Global and MasterCard.

    The business came into being when co-founders Jack Zhang and Max Li–who both worked in the banking sector–started a cafe in Melbourne’s Docklands area and realized that expensive foreign exchange rates hurt their profit margins when they imported products such as coffee cups.

    Zhang was a software developer working in investment banking and foreign trading, and he knew technology could be applied to the problem.

    Four years later, the company operates a network that allows SMEs to make easy and affordable payments to more than 130 countries and in 50 currencies.

    Airwallex has 400 employees spread across offices in Hong Kong, London, Melbourne, Shanghai, Shenzhen, San Francisco, Singapore and Tokyo. That headcount includes 50 engineers in Melbourne and 84 in Shanghai.

    “Communications between the two teams is incredibly important,” said Peter O’Donovan, Airwallex engineering lead.

    So the approach has been to treat all of his people as if they were remote workers.

    Tools

    Extensive use of Slack–even when both people are in the same office–keeps everyone in the loop, he explained.

    Similarly, Zoom videoconferencing is used for standups, and physical agile walls are replaced with digital equivalents.

    These tools also allow for the growth of skills across regions, and help ensure everyone is “working to a common pattern.”

    Such shared channels for collaboration and communication help accommodate overlapping working hours (Melbourne and Shanghai are three hours apart when daylight saving is in effect in Australia), as well as the need for engineers to be on call to deal with emergencies.

    This approach puts everyone on a similar footing, whether they work in one of the offices or remotely.

    DevOps leaders need to “focus on building relationships first,” he advised. Frequent video conferences are one way to build bonds with people in different locations. Understanding each others’ mindsets, establishing common ways of working and setting clear expectations are essential, and “doing it from day one is important.”

    Scaling up

    Airwallex plans to double the size of its engineering staff in both cities during 2020. O’Donovan points out that these established standards and practices help with the onboarding process and allow new hires to become productive more quickly.

    That is especially true as the company has selected tools that most people will find familiar: in addition to Slack and Zoom, Airwallex also uses GitHub and G Suite. “These tools are easy to adopt and easy to consume.”

    “Melbourne is a challenging market,” said O’Donovan, because DevOps skills are in demand and Airwallex wants to hire and retain quality talent. But there’s a virtuous circle–helping staff build a strong skill set and surrounding them with other talented people makes it a better place to work, so attraction and retention becomes less of a problem.

    O’Donovan sees DevOps as a key to scaling the company. Having all the teams using the same tools and patterns yields economies of scale by avoiding unnecessary repetition of work, and it allows developers to focus on functionality rather than plumbing.

    Furthermore, regulation and compliance is particularly important in the finance sector, and those considerations need to be built into the processes. “If you can do that seamlessly, you’re doing a good job,” said O’Donovan.

    For example, making vulnerability scanning and the segregation of duties the defaults in the CI/CD pipeline addresses such issues in an automated and auditable manner.

    You need “the right mindset for finance,” he warned. Building in compliance from the start works; trying to add it as an afterthought does not.

    Don’t segregate people, advised O’Donovan, because everyone needs to be working collaboratively toward the same goal. With the right tools and automation, a cross-functional team can deliver better code, faster.

    — Stephen Withers

  • Using Open Source for Better DevOps Outcomes

    Using Open Source for Better DevOps Outcomes

    Many insurers have jumped on the DevOps bandwagon in order to improve the efficiency and effectiveness of their systems and systems implementations. Very few insurers, however, spend much time thinking about the open source software community as a way to improve their DevOps approach–and the skills of their developers–and in that regard they’re missing a golden opportunity. In fact, insurers often restrict their developers from updating or contributing to open source libraries because they don’t realize the potential benefits available to them by participating more actively in the open source community.

    A 2016 survey by 451 Group indicated that the more companies used open source solutions in their DevOps portfolios, the more effective the DevOps function was. More specifically, the study reported that among companies with at least 60% of their DevOps portfolio as open source, a full 54% had reached the “fully deployed” DevOps state, with all of their development occurring via DevOps models.

    By comparison, only 30% of the surveyed companies that used less than 60% of open source tools in their DevOps portfolios had reached this state of DevOps adoption. Clearly there’s a link between open source use and DevOps success. Given these results, insurers should focus on the benefits of supporting and encouraging their DevOps groups to embrace the open source community.

    It’s a dated but still persistent view: Participating and contributing to the open source community means developers are giving away their time by creating and contributing intellectual property (IP) that may benefit others outside the organization. However, the truth of the matter is participating DevOps engineers, developers, analysts, etc. are often fixing bugs and making improvements to code libraries other than their own but that can have value for their own DevOps efforts.

    The very definition of open source –software for which the original source code is made freely available and may be redistributed or modified–makes it fertile ground for skills and solutions improvement. Additionally, that process of analyzing and repairing code represents some serious skills development. It’s the kind of development skills that can be difficult to obtain by just working on in-house applications and platforms–which are often proprietary and dated–lacking modern coding techniques.

    Since open source literally means a developer and/or organization has the ability to make the code fit their needs however they see fit–they control their own version of the product that may diverge from the original open source project–the opportunity for DevOps solutions improvement is substantial. Moreover, any DevOps related IP a developer creates and contributes is not lost and is certainly not stolen–the IP can be used directly by the developer and that developer can continue to benefit from the IP of other developers on a gratis basis.

    Utilizing DevOps solutions from the open source community can be both time and cost effective and can be a positive boon to organizations. While some insurers may not knowingly allow open source code in core systems or applications, its use in a DevOps ecosystem is another matter. That’s especially true since DevOps is a newer and less mature IT function that requires new tool, process and solutions development. Leveraging open source solutions can expedite that process. In fact, many of the key DevOps tools used today either are or started as open source solutions for DevOps problems. One would be hard pressed to find a DevOps development stack–from building/developing to monitoring–that didn’t use at least one open source tool as part of the stack.

    Often the fear or apprehension to using open source libraries (for DevOps or anything else) is that anyone could have written it, thus its quality is or could be sub-par. While in some cases this can be true, the same holds true for closed source proprietary software, as many insurers could attest. Simply put, open source tools and libraries are worked on by developers of the exact same caliber–if not the exact same people–who work on closed source proprietary tools and libraries. The only difference is there are often less people involved with proprietary solutions development. And since there are relatively few proprietary DevOps solutions in the marketplace to choose from, open source should be considered a viable channel for DevOps solutions.

    Even if there were more choices for proprietary DevOps solutions, the financial savings involved in combining open source solutions with DevOps can be significant. Importantly, open source solutions for DevOps are particularly useful when the right solution for a problem has yet to emerge, almost a given in a maturing DevOps ecosystem. Rather than rushing out to buy something that promises to fix the problem–or writing something themselves–DevOps developers can find open source solutions and use those to experiment, test and otherwise isolate and identify the true nature of and solution to a DevOps challenge.

    Another reason DevOps groups should avail themselves of open source techniques and tools is the fact that the tools and techniques available for DevOps–proprietary off the shelf and built inhouse–are still not quite there yet. The tools available are almost always missing something, resulting in developers at many organizations spending most of their time–and the organization’s money–trying to develop fully functional solutions from the ground up.

    More often than not, the resulting tool or solution is never as complete or well-built as the open source tool or solution that already exists. Most organizations would be better served tasking their developers with scouring open source libraries, identifying the “best fit” DevOps tools and then spending the time required creating the updates and improvements to the tools that have already been mostly built, saving time and money.

    Finally, there are lots of DevOps staff out there who participate in the open source community–in their spare time anyway, or have done so while working on previous projects. That means hiring DevOps staff with open source experience is a shortcut to potential open source techniques and tools. These are people that can hit the ground running by bringing their open source experiences to bear while they’re getting up to speed on the proprietary work they may be assigned. Considering these benefits, it’s past time for DevOps groups at insurers to dive into the open source waters.

    — Tanner Gibson

  • The Challenge of Scaling Metrics in Distributed Systems

    The Challenge of Scaling Metrics in Distributed Systems

    Whether migrating from a monolithic architecture or building a distributed system from ground zero, there are many benefits to leverage from a microservices architecture–faster software deployment cycles, enhanced scalability, improved isolation of risk. However, distributed systems are complex and as such, accompanied by many challenges, particularly when it comes to the scalability of metrics.

    The Importance of Observability in Distributed Systems

    In order to realize the benefits of a distributed system, a strategy of data-driven optimization is essential. The paradox here is visibility simplifies complexity, while the complexity of visibility is dramatically increased in distributed systems.

    As New Relic points out in their eBook Cloud Native Is the New Normal, traditional monitoring approaches need to be adapted to meet the demands of decentralized architectures, including:

    • Overcoming the loss of end-to-end monitoring capabilities by learning how to connect the dots across a complex network of environments.
    • Developing tactics to quickly drill down into issues across interconnected parts to reduce mean time to resolution (MTTR).
    • Introducing proactive reliability strategies that focus on measurement first, followed by improvement.

    Finding the Right Balance Between Monitoring Nothing and Monitoring Everything

    Most application engineers leverage some sort of metrics tooling such as Grafana, Prometheus or Graphite to track vitals for their system health. While monitoring is essential, there is such a thing as bloat when it comes to metrics ingestion; and this overload translates to scalability challenges that affect performance, cost and reliability.

    So, how do you know what to monitor? In order to derive the most valuable insights from your system, you must first understand and identify the components, and more specifically which attributes within those components drive key metrics. Knowing this requires an intimate familiarity with how all the pieces work together in your distributed system.

    Google’s Site Reliability Engineering book provides a framework for determining what to monitor in distributed systems. They break signals down into four different categories:

    • Latency: Understand resource requirements and identify bottlenecks.
    • Traffic: Monitor system response to varying levels of load; most useful when paired with other indicators.
    • Errors: Track frequency and nature of interruptions in request/response flow.
    • Saturation: Surface capacity-related issues.

    Even when you’ve identified the most important metrics to track, scalability is still a challenge that must be addressed, particularly when dealing with applications that handle massive volumes of data across a complex application architecture.

    M3: Uber’s Open Source Large-Scale Metrics Platform

    A solution directly addressing the challenges of distributed metrics at scale is M3, an open source project developed by Uber’s engineering team.

    Before using M3, the Uber team sent metrics to a Graphite stack with storage handled using the Whisper file format in a shared Carbon cluster. From there, they created Grafana dashboards to visualize the data and used Nagios for alerting based on Graphite threshold checks via source-controlled scripts. As the volume of metrics continued to expand, manual processes to scale the solution became unsustainable and repeat failures resulting in permanent data loss led them to build a more fault-tolerant, scalable system.

    M3 is focused on providing a reliable storage solution for large-scale metrics over long retention periods, solving inherent single node-associated limitations with Prometheus by offering a multi-tenant store for Prometheus metrics. A key component of this solution is M3DB, the scalable storage backend for M3.

    M3DB, built in Go, is a distributed time series store and reverse index with configurable out-of-order writes. By enabling the storage of real-time metrics over long periods of retention, M3DB can replace a Prometheus cluster. In developing the M3DB solution, the Uber team essentially deconstructed Prometheus into microservices to enable the scaling of each component individually. By taking this approach, M3DB is able to offer better reliability, efficiency and performance.

    At a minimum, M3DB can be leveraged as remote storage for Prometheus (or used to replace any other remote storage solution). There are, however, other features the solution offers, including an external aggregation engine and a separate query engine.

    The M3DB project is still under development with a growing community of contributors.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Molly Wojcik