devopsy.kinsta.cloud

Tag: microservices

  • Collibra Employs Microservices for Data Management

    Collibra Employs Microservices for Data Management

    Collibra has launched a Collibra Data Intelligence Cloud based on a microservices architecture that promises to alter the way data is managed in enterprise IT environments.

    Jim Cushman, chief product officer for Collibra, said its approach sets the stage for leveraging microservices to create data workflows made up of reusable components. In fact, there may come a day soon when some data sets are accessed and managed as a reusable microservice, he said.

    The Collibra Data Intelligence Cloud provides a catalog for managing metadata that, in addition to making it possible to build workflows, ensures the integrity and security of data being accessed and stored. End users can then analyze that data using a wide variety of third-party tools, said Cushman.

    At the same time, Collibra enables metadata ingestion from data sources such as data lakes and data warehouses, which means IT teams don’t have to move all the data they need to manage into Collibra Data Intelligence Cloud to create a workflow.

    Collibra is also making available a beta version of its Data Matching tool for qualified customers. That tool identifies duplication within a data source and how that data might overlap with other data sources.

    Finally, Collibra has added a data scoring component to its catalog to identify the most relevant data sets; provide enhanced support for third-party business intelligence (BI) and extract, transform and load (ETL) tools; and strengthened rights management capabilities to make it easier to enforce compliance requirements.

    Cushman said the goal is to provide organizations with an easier approach to storing and organizing trusted data. As the amount of data an organization collects grows, so, too, does the opportunity for conflicting data to be incorporated in applications. The Collibra Data Intelligence Cloud creates an opportunity to make data universally available to applications without requiring them to copy it, he said, noting that approach reduces not only the amount of data that might be in conflict as data sources are updated but also the amount of infrastructure that would have been required to process and store duplicate data.

    Organizations have been struggling with data management since the dawn of IT. That’s become a more pressing issue as more organizations seek to turn data into a strategic asset that drives digital business transformation initiatives. However, those initiatives are often derailed because so much of the data is either conflicting or simply too stale to be relevant. Collibra is making the case for a single platform to bring order to what historically has been a chaotic process.

    It’s not clear to what degree organizations will be focusing more on data quality and management in the months ahead. In the wake of the economic downturn brought on by the COVID-19 pandemic, it’s clear digital business transformation has become a necessity. The challenge is that unifying how data is managed in any enterprise requires a massive amount of political capital. Each business unit within an enterprise IT environment tends to guard its data privileges jealously.

    However, as microservices make it possible to make the business a lot more agile, the day when organizations finally confront their longstanding data management issues may finally be at hand.

  • How to Use Microservices To Evolve DevOps Pipelines

    How to Use Microservices To Evolve DevOps Pipelines

    Enterprises are quickly becoming an intricate mesh of many applications. As companies create more and more microservices, their deployment environments are becoming increasingly elaborate. Without proper configurations, a microservices road map could quickly become unmaintainable.

    According to DeployHub CEO Tracy Ragan, if development teams are pushing points to a cluster continuously, application development can suffer without high visibility into their dependencies and application interrelationships.

    In her recent talk, “Evolving Your Pipeline for Microservices with DeployHub,” presented by the Continuous Delivery Foundation (CDF), Ragan, also Governing Board member of CDF, discussed ways in which teams can obtain improved insight into microservices delivery pipelines.

    Microservices Tracking Issues

    A 2018 study conducted by O’Reilly found that 86% of respondents reached mild success in adopting microservices in production. Only 15% reported “massive success.” These results demonstrate both the excitement surrounding microservices and the rarity of flawless execution.

    “I’m a huge fan of microservices,” said Ragan. “This is an exciting time to be in software development.” Microservices break from the traditional software delivery model, she said, forcing teams to emphasize the runtime. However, with this shift, it becomes easy to lose the logical views between applications.

    According to Tracy, dependency tracking and version control are top issues in maintaining microservices arrangements. With continuous updates, it can be challenging to keep track of which version a service is using. “Microservices development falls apart without a coherent management approach,” she said.

    Losing Visibility Moving From CI to CD

    Part of the loss of visibility stems from the move from CI to CD. Continuous integration (CI) involves routinely updating source code and starting the compile process. This is often done every hour, as opposed to every week or month. With traditional CI, the system created a package and scanned for dependencies at compile. This was the first step in the continuous journey.

    However, nowadays, microservices are typically linked at runtime or in the Kubernetes deploy file as part of a continuous delivery (CD) processes. In doing so, we’ve lost a certain amount of visibility that CI granted. Ragan likened it to “hammering a wine glass”—we still have the constituent parts, but they lie shattered in pieces.

    Large microservices suites of 50, 100 or even 300 are not uncommon these days. Such large ecosystems require logical tracking of versions and dependencies. Ragan argued that development teams need a workaround layer to replace the critical configuration management lost in CI compile reports. Visibility into interrelationships is necessary to trace how changes in one service will impact other applications.

    Enter Ortelius

    Ortelius is a package that helps with continuous microservices management. Ortelius, named after Abraham Ortelius, the inventor of the first atlas, helps trace the connections between services to improve an ecosystem’s visibility.

    To get an idea of how it behaves, consider an e-commerce store. To reach an evolvable microservices pipeline, each microservice should be independently deployable with its own workflow. For example, an e-commerce store may require a product microservice, payment microservice and an authentication microservice. These reusable components are independently deployable but rely upon one another to function as a whole.

    At a macro scale, an enterprise with thousands of inter-application dependencies would visually resemble a constellation of nodes. An extreme example of this may resemble the Netflix Death Star, a mass conglomeration of intersecting points. Ortelius grants transparency into an otherwise tangled mess as an “internal marketplace for microservices,” said Ragan.

    Paring Ortelius With DeployHub

    Ortelius is the open source core of DeployHub, an open source SaaS for sharing and releasing microservices. Ortelius, paired with DeployHub, enables teams to see the logical application map, exposing the complexity of microservices dependencies.

    Developers add DeployHub to any existing microservice development workflow prior to release. Ortelius is then called to increment the service and record dependency information. DepoyHub then uses for Helm or Ansible for the actual code push, and adds the record metadata and adds the tracking and mapping layer. Having such information is still critical for reporting like dif reports or a bill of materials report, noted Ragan.

    This sort of solution, Ragan proposed, is also vital for continuous configuration management—when a microservice changes, the team will always be aware of the new application version.

    The New Microservice Pipeline Model

    As noted above, in the traditional model, DevOps teams map dependencies in the CI stage. When an API developer publishes to the main catalog, they define specific attributes based on the microservices. A versioning engine will then typically map to visualize dependencies.

    Ragan outlined steps for a new microservices pipeline:

    1. Build image: Compile and build the container image.
    2. Put into registry: Quay or Docker registry. Specific for container registries.
    3. Track service-application configurations: This is where we collect configuration data to map the structural relationships.
    4. Push to cluster: DeployHub helps to standardize this process across an organization.
    5. Collect feedback: Configuration reporting and impact analysis.

    Core to this process is being able to independently deploy microservices and aggregate useful information. Of course, this is an incomplete model—a complete pipeline would utilize other steps including testing and automated security scanning as well.

    Benefits

    By streamlining the microservices journey in this way, repos will be broken out and teams no longer go through one big long workflow. According to Ragan, the visibility garnered from this method could help organizations in multiple other ways:

    • Reduce time: Ragan estimated automated application relationship mapping could replace one to two hours of manual work per week per development team.
    • Reusability: Decomposing applications into their domains aids reusability across an organization.
    • Avoid redundancy: Code sharing can significantly reduce duplicated code, thus avoiding redundancy and increasing flexibility.
    • Visibility: Detailed application to service relational knowledge could empower SREs to make better data-driven decisions.
    • Centralize: Helps standardize container deployment processes regardless of cluster type or collection, aiding both traditional and containerized microservices deployments.
    • Versioning: Improved insight into versioning helps when you need to share services externally.

    Lastly, what’s nice is Ortelius is open source on GitHub. Ortelius adopts an open community format to accept feedback. “Democratization is the core reason we have open source,” said Ragan. Ortelius can be used for free, or with added features from DeployHub pricing for enterprise cases.

    A Confluence of Software Delivery Styles

    Managing continuous software delivery across many microservices leads to unprecedented issues. In solving these issues, the industry appears to be fracturing slightly. For example, the model promoted by Ragan is in contrast with a recent presentation I covered from Codefresh.

    Where Ragan suggested improving visibility into independent microservices deployment pipelines, Dan Garfield of CodeFresh suggested adopting a single CI/CD pipeline to operate all microservices from a single control plane. As it goes so often in software tooling, the use case will likely dictate adoption.

    Whatever the software delivery process, when decomposing applications—or “taking the hammer to the wine glass,” as Ragan called it—we probably shouldn’t sacrifice visibility into the metadata associated with application versions and service to application interrelationships. If such data is lost or not managed correctly, we could lose a lot of potential value.

    For more information on evolving DevOps pipelines, watch the CDF-presented webinar here. DeployHub also published an adjacent article on this subject here. You can also contribute to Ortelius on GitHub.

  • Microservices vs. Monoliths: Which is Right for Your Enterprise?

    Microservices vs. Monoliths: Which is Right for Your Enterprise?

    With microservices projected to grow globally at a 22.5% rate between 2019 and 2025, the choice between monolithic and microservices architectures needs to be carefully considered. If you are wondering what microservices are best suited for, or whether your business should stick to monolithic or switch to microservices, here are a few cardinal points to take into consideration.

    What Is Monolithic Architecture?

    A monolithic application is built on a single code base with a variable number of modules. The number of modules depends on the complexity of the business and its technical features. The whole application—and dependencies, when applicable—are built on a single system with a single executable binary for deployment.

    A monolithic architecture has distinct advantages and disadvantages that should be evaluated when deciding when selecting the optimal type of architecture for the application.

    Monolithic architecture pros:

    • Fewer cross-cutting concerns: The majority of applications typically have a large number of cross-cutting concerns. Running them all on a monolithic architecture facilitates hooking up components.
    • Less operational overheads: Avoids the additional costs stemming from microservices such as interservice communication, service discovery and registration, load balancing, decentralized data management or distributed logging, for example.
    • Complex testing: Testing for microservices is considerably more complex than for monoliths.
    • Better performance: As shared-memory access is faster than interprocess communication, a monolithic architecture typically has better throughput performance.

    Monolithic architecture cons:

    • Overly tight coupling: Entanglement increases the difficulty of isolating services for upgrades or independent scaling when the application evolves.
    • More difficult to understand: As the application grows and the number of layers and dependencies increases, understanding the system becomes increasingly difficult.
    • Slow build and test create releases: Upgrades imply recoding the entire application to factor in the dependencies and side effects.
    • Hard to distribute development: Tightly integrated applications are difficult to break into chunks, which complicates the creation of a distributed team effort.
    • Usually requires opting for a single programming language: Integrating more than one language in a monolithic application is fraught with challenges, typically preventing the integration of components written in a different language, which might limit the flexibility of adding features best suited to an external language.
    • Complicates the adoption of third-party tools: Adding self-contained third-party components, for example, cloud-native, to a single code base with multiple dependencies requires complicated hookups to different layers of the monolithic application.

    What Is Microservices Architecture?

    Microservices architecture is designed to accommodate the need for large application development by providing a suite of modular components and services.

    When considering what microservices are particularly well-suited for, the following advantages and disadvantages should be taken into account:

    Microservices pros:

    • Better organization: Microservices are organized around business and technological capabilities, in units that are independently deployable.
    • Decoupled: Each unit can be independently upgraded without requiring a complete overhaul of the application.
    • Performance: Flexibility in opting to privilege performance or flexibility as needed, including independently scaling heavily used services by isolating them from the remainder of the application.
    • Fewer mistakes: The hard-to-cross boundaries between microservice units limit the technical possibility of generating mistakes, notably cascading ones.
    • Easier onboarding of new developers: They only need to master the microservice unit they will work on instead of the entire application architecture.
    • Scalability: Each microservice can be scaled independently, while also adding new components.
    • Improved fault isolation: As modules work independently from each other, a failure in one module does not affect another.
    • Elimination of vendor or technology lock-in: As each microservice module can be operated independently, replacing underperforming modules with better ones from an alternate vendor is relatively easy.
    • Ease of understanding: As services are broken down into modules, understanding the functionality of a module is easy for developers.
    • Smaller and faster deployments: Each service can be scaled independently as needed, instead of scaling the entire application. This can lead to cost savings.

    Microservices cons:

    • Cross-cutting concerns: Microservices require handling cross-cutting concerns such as externalized configuration, logging, health checks, metrics, service registration and discovery and circuit breakers, as well as those specific to the technologies used by the microservices.
    • Higher operational overhead: Microservices deployment typically leads to an increase in the number of units and containers, increasing the management and operation cost overheads.
    • Security threats: Microservices architecture presents an expanded attack surface. Securing a containerized application requires managing privileged access at image, container, node, pod and namespace levels, ensuring encrypted tunneling from ingress to egress and other elements that require baking in security from the beginning.
    • Multiple complexities requiring management:
      • Communication between services on a technological level, and between teams on an operational level.
      • Selecting the optimal pattern from the several microservices patterns available.
      • Provisioning sufficient IPs.
      • Provisioning resources (memory, CPU, disk) to accommodate each cluster requirements.
      • Maintaining multiple programming languages and frameworks.
      • Handling the incompatibilities between existing tools and new service dependencies.
      • Accounting for automation tools for each service requiring individualized testing and monitoring.
      • Achieving data consistency between each service’s individual database and transaction management system.
      • Handling the number of processes that can grow exponentially when load balancing and messaging middleware are considered.
      • Provisioning for the increase in documentation overhead stemming from the need to keep schemas and interface documents up to date.
      • Refactoring of an application built on monolith architecture is a massive undertaking for large enterprise applications.
    • Complicated global testing: Global testing requires that each dependent service be tested first. This can be partly assuaged with automated testing.
    • Difficulty in debugging problems: Debugging requires inspecting each service log independently, increasing the workload.
    • Deployment challenges: Microservices are written in a variety of frameworks and languages and require distinct resources, scaling and monitoring, making orchestrating the deployment challenging.
    • Large versus small product companies: Though the benefits of microservices are invaluable for large companies, adopting a microservices architecture creates overwhelming complexities leading to slower implementation and unnecessary cost increases for small companies.
    • Higher costs: Without careful and strategic planning, cloud service bills may balloon due to the increase in data stemming from intraservices calls and the increase in resource requests to account for scalability and lack of friction.
    • Cultural changes: Microservices require the company to have an agile DevOps culture.

    As microservices architecture provides a better way to manage growing data sets, leverage cloud storage and automation and deploy solutions fast, microservices are usually preferable to monoliths. However, they might not always be the best choice for an organization. Before opting for microservices, a careful examination of your company culture and business objective is imperative.

  • Puppet Launches Relay to Simplify Automating DevOps Workflows

    Puppet Launches Relay to Simplify Automating DevOps Workflows

    Puppet today made available a public beta of Relay, an event-driven platform through which DevOps teams can automatically invoke pre-configured workflows.

    Company CTO Deepak Giridharagopal said Relay listens for DevOps events that can then trigger an automated workflow such as automatically deleting underutilized cloud resources, enforcing cybersecurity controls or remediating known issues.

    Relay connects to dozens of DevOps tools, cloud services and application programming interfaces (APIs) to automate workflows across a wide range of platforms, including PagerDuty, GitHub, Datadog, Jira, Terraform, Slack and others.

    Giridharagopal said Relay will also enable IT organizations to reuse workflows versus continually cobbling together one-off workflows for processes that address routine use cases that can be tackled using existing content.

    At the root of that issue is tool sprawl within DevOps environments. Each DevOps team tends to create their own workflows using their preferred tools, even though they may be replicating a workflow process that has already been addressed using other tools. Relay provides a means to reuse workflow across disparate DevOps tools, which Giridharagopal said should significantly increase overall DevOps productivity.

    The Relay platform is also designed to be extensible in that it also allows DevOps teams to create custom workflows that can then be reused by other members of DevOps teams, he added.

    Giridharagopal said with the rise of microservices it’s apparent workflow automation within DevOps environments is about to become a more pressing issue. As the number of individual services that need to be managed increases, the need to automate workflows across more complex IT environments becomes more critical. DevOps teams can’t effectively manage modern cloud-native applications relying on manual workflow processes, he said.

    Relay is part of a broader shift toward event-driven architectures, which are gaining increased traction within IT environments. While event-driven architectures have been around as a concept for decades, the emergence of platforms based on, for example, serverless computing frameworks are changing how IT resources are invoked. Via any number of APIs, it’s feasible to automate a wide range of IT functions using these types of platforms.

    Of course, the biggest challenge for many organizations has been building automated workflows that work consistently across multiple platforms. The level of process expertise required to build those workflows is not inconsequential. Puppet, via Relay, is providing pre-configured workflows to address some of the more common use cases in a DevOps environment. DevOps teams will still need to build their own custom workflows to address more complex use cases. However, platforms such as Relay promise to sharply reduce the time spent creating scripts and associated workflows to address routine tasks.

    In the meantime, interest in all forms of IT automation is on the rise in the wake of the economic downturn brought on by the COVID-19 pandemic. IT organizations are moving quickly to reduce the total cost of IT by automating as many processes as possible. In many cases, it’s not clear when some IT organizations might be able to add additional headcount anytime soon. Automation, as such, is now as much about survival as it is simply trying to increase productivity.

  • A10 Networks Allies with Dell for ADC Infrastructure

    A10 Networks Allies with Dell for ADC Infrastructure

    A10 Networks announced today it has partnered with Dell Technologies to make its application delivery controller (ADC) and A10 Thunder Multi-tenant Virtual Platform (MVP) available on Dell servers.

    Gunter Reiss, vice president of worldwide marketing for A10 Networks, said this alliance reduces the cost of deploying ADCs in on-premises IT environments by taking advantage of industry-standard hardware platforms based on x86 processors beginning in the third quarter. Those servers, however, will only be available in the Americas market.

    Specifically, the A10 Thunder ADCs are designed to run on Dell EMC PowerEdge R640XL and R740XL servers, as well as Dell EMC Virtual Edge Platform 4600. The A10 Thunder MVP is designed to run on Dell EMC PowerEdge R640XL and R740XL servers. IT teams can move A10 ADC licenses across these platforms as they best see fit, said Reiss.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, A10 Networks expects more IT organizations will look to rationalize their server portfolio, he said, noting as a major supplier of those servers, partnering with Dell affords A10 Networks an opportunity to expand the base of potential customers.

    Standardizing on a single server platform also affords some organizations the opportunity to reduce their carbon footprint in the data center, he added.

    It’s too early to say how aggressively IT organizations will be consolidating IT infrastructure. However, the total cost of IT increases whenever an organization adds a new platform or vendor. Many IT organizations have already standardized on a single server vendor as part of an effort to reduce management costs. In fact, Reiss said A10 is betting rival ADC vendors will be shut out of IT environments if they require IT organizations to acquire dedicated hardware.

    In the meantime, the number of ADCs required by IT organizations is increasing as the application environment becomes more complex. The rise of microservices-based applications is requiring IT teams to focus more on application latency issues that occur when more modules of code are sharing access to the same IT infrastructure.

    A10 Networks helps address that issue by embedding analytics into that A10 Harmony Controller that is employed to centrally manage all A10 ADCs deployed in a distributed computing environment. That capability makes it simpler for IT organizations to embrace best DevOps practices, Reiss noted.

    ADCs are also playing a larger role in security by first offloading encrypted SSL/TLS traffic and then providing visibility into that traffic to prevent data leakage.

    In general, Reiss said DevOps teams are exercising more ownership of ADC platforms. Network and security operating teams still play a major role; however, it’s clear IT functions are starting to converge, he said.

    It remains to be seen to what degree those roles will ultimately converge. Each IT organization is likely to pursue a slightly different path toward converging network operations and DevOps. The challenge and the opportunity will be overcoming the inherent cultural challenges associated with bringing together IT teams that historically have not had much cause to interact with one another.

  • Hasura Launches Beta of GraphQL-Based Remote Joins Tool

    Hasura Launches Beta of GraphQL-Based Remote Joins Tool

    Hasura today announced the public beta of Remote Joins, which makes use of an open source GraphQL query language for application programming interfaces (API) to join disparate data sources residing in different repositories.

    Company CEO Tanmai Gopal said Remote Joins extends a GraphQL engine the company has developed around a project that is now hosted by the GraphQL Foundation, an arm of the Linux Foundation. The GraphQL Foundation counts among its members Airbnb, Amazon Web Services (AWS), Apollo, Coursera, Elementl, Facebook, GitHub, IBM, Intuit Hasura, Paypal, Prisma, Shopify and Twitter.

    Originally developed by Facebook, GraphQL has emerged as the basis for a more streamlined alternative to REST APIs. GraphQL provides a complete description of the data made available via an API and is organized in terms of types and fields rather than traditional endpoints. In addition to making it more clear what data is available via that API, developers can employ types to avoid writing manual parsing code.

    Hasura is now taking that concept a step further by enabling IT organizations to join data residing in different databases and microservices to enable that data to be queried as if it were a single data source. The core Hasura engine automatically generates the GraphQL engine, which enables those remote joins to be created in a few minutes.

    Gopal said joining data across a complex portfolio of modern applications based on microservices and legacy monolithic applications is becoming increasingly difficult as the number of microservices in an IT environment continues to proliferate. The Hasura engine addresses that issue by providing data access and flow tool base on a GraphQL type system for managing APIs that can be applied to GraphQL APIs as well as REST APIs or other protocols, he said.

    The join, authorization logic and consistency checks are all managed by the Hasura engine. Hasura also provides data change management, observability, auditing, security and performance management capabilities. That approach makes it possible for data sources and APIs to evolve independently while still allowing organizations to query data flexibly, noted Gopal.

    As DevOps and DataOps processes continue to converge, IT organizations will need to find a way to advance application and API development in a way that doesn’t result in data access becoming a major bottleneck. Too many DevOps teams are rapidly building applications and APIs only to find themselves waiting to be given access to data. GraphQL could provide a foundation on which IT teams can manage DevOps and DataOps processes more collaboratively.

    It’s not likely IT teams will be replacing existing REST APIs wholesale overnight. However, it’s also apparent that REST APIs may not enable IT environments to scale as efficiently as GraphQL, which is the primary reason why Facebook developed it. Of course, it’s still early days as far adoption of GraphQL is concerned. However, with more IT teams under pressure to innovate faster, interest in a more streamlined approach to building and managing APIs is likely to gain additional momentum.

  • Working with SAFe and Microservices: Learnings from Developers

    Working with SAFe and Microservices: Learnings from Developers

    As developers, the prospect of working for a big company might bring about feelings of oppression, rather than opportunity. Envisaging endless team syncs, pointless meetings and processes wrapped up in bureaucracy inside a set of procedures. It’s easy to imagine why some are put off. For many though, the fear comes from the thought of being lost in a corporate structure where input is not valued, and skills are wasted.

    But every day, as developer concepts become further rooted into corporate behaviors, the line between the two worlds continues to blur. Products are no longer dreamed up in product silos, but from agile teams made up of a diverse cross section of a company. Marketing has dropped drip campaigns in favor of A/B testing, rapid iterations of messaging and data-driven analytics. Big companies no longer mean old school thinking, but fast-changing, inclusive places to really make an impact and be heard. 

    Working within the Scaled Agile Framework (SAFe) with an agile architecture of microservices helps us to do our jobs, but the learnings we’d like to share in this article are universal. An organization may not require the SAFe methodology, but the experiences and methods of working can be applied to many roles and are based on three fundamental questions every developer should ask themselves. 

    How Do I Plan My Day? 

    As with any role, a good start for us is knowing that the previous day went well; that the code we wrote meets the standards required for deployment. Before that, our individual microservices teams will meet to discuss immediate priorities. We let one another know what’s top of mind for us, and any issues we might be facing — and we resolve them together before a midday Scrum meeting.

    The Scrum meeting involves the Scrum master, product owner and the developer team and gives us a chance to give feedback and dive into the wider challenges or blockers we’re facing with our own tasks. We might be thought of as solitary creatures, but we actually tend to solve problems together. So, while we have ownership of our own tasks, problem solving comes from collaboration.  

    Whether working within the agile framework or not, communication is a huge part of our lives. Our advice to developers everywhere is to be vocal about the need to engage within their organizations. And to business IT decision makers, we know that not every firm has the deep pockets to fund a dedicated DevOps team to implement new tools, change culture or break down silos, but there are many communications and open source DevOps tools that boost collaboration and improve workflows — most are well-known to developers. So, give them the chance to explore how they might bring efficiencies to their work. Help them help the business and maybe suggest trialing some new tools. 

    How Do I Upskill on the Job?

    Developers are problem solvers. We love the opportunity to help each other overcome challenges. Peer-to-peer communication doesn’t just allow us to get back on course quicker, it lets different teams share knowledge and pitch in to solve problems. We don’t mind being transparent with our peers when we face an issue – in fact, we quite like it, as the offshoot of working together often leads to new skills and technical knowledge. 

    Learning the interactions between each microservice, for example, helps us map out the architecture and understand how our own work fits into the bigger picture. The more we talk, the more we see where bottlenecks might occur — and the better equipped we are to achieve larger objectives. As we have complete ownership of our services, from initial coding to deployment, it is our duty to ensure our services perform as they should in production. 

    This ownership is something all developers should aim for. Even when working in a more rigid waterfall approach, opportunities to collaborate should be seized and encouraged — even if the only payoff is personal development. Implementing a system of peer code reviews, for example, not only delivers more robust releases, it fosters a collaborative mindset.

    Do I Need to Be in this Meeting?

    Working with SAFe methodology allows the job to be broken down into iterations linked to business objectives. The most significant of these is determined by meetings that occur every four months, where goals are set and roadmaps established to achieve them. Engineering teams then divide up the features that will be passed on to the developer teams, who break them down into two-week sprints. 

    The sprints are what the developer teams work to, under direction from the Scrum masters and product owners. Breaking iterations into smaller sprints ensures we have defined goals, which keep meetings and interactions on track (i.e., daily Scrum meetings and bi-weekly sprint meetings). Without this focus, there’s a risk of derailing the prep required to focus on writing and reviewing code. If we need a discussion about certain features, we make sure to identify exactly who needs to be in that meeting. Above all, we’re all about optimizing our time together. The longer we spend away from our desks, the less time we have to perform our core roles. 

    Whatever your part in the software development lifecycle, never be afraid of asking the question, “Do I need to be here?” Your energies may be best used elsewhere.

    As you can see, these three questions are critical to developers but can be applied to just about any role in just about any organization. Planning, learning and focusing – seems we’re not so different after all.

     

    Tomasz Rumpca

     

    This article was co-authored by Tomasz Rumpca, Java developer and team lead at Finastra. Tomasz works on FusionFabric.cloud, Finastra’s open development platform solution. He is passionate about Java-related technologies and building user-friendly software. Outside of work, he enjoys spending time outdoors with his friends and family.

  • Application Architecture

    Application Architecture

  • How to Scale Microservices CI/CD Pipelines

    How to Scale Microservices CI/CD Pipelines

    As opposed to a traditional monolith, microservices architecture can theoretically bring many benefits. Microservices decouple software elements, enable reusable components and allow independent development cycles. However, in practice, microservices are prone to many issues.

    For example, teams accustomed to a traditional monolithic build process may find it difficult to reshape their established practices. Furthermore, as the number of microservices increases into the hundreds, managing separate CI/CD pipelines for each service becomes untenable, especially as DevOps components aren’t always optimized to fit every pipeline precisely.

    These are some of the real-world problems that Dan Garfield, chief technology evangelist at Codefresh, brought up in episode five of the DevNetwork Dev Professional Series. In this article, we follow his talk to examine the benefits of microservices, their hangups in a real-world CI/CD case study and solutions for scaling delivery as complexity and numbers increase.

    Monoliths in Space

    To get a better idea of why we need microservices, Garfield uses an analogy from space—the Apollo 13 mission. Apollo 13 was made of two ships: the lunar module and the command module. In software terms, these were essentially two giant monoliths.

    When the command module experienced an oxygen failure, its crew needed to repurpose oxygen filters from the lunar module. However, the lunar module engineers designed their oxygen filters differently, causing a major headache to reassemble and retrofit these parts.

    This analogy goes to show how monolithic-style development can create tunnel vision. When teams adopt guidelines that work only for the monolith, they are usually incompatible externally. This stifles the possibility of reusable components, thus decreasing code value and extending overall development effort.

    “Being able to reuse components and scale independently is the benefit of microservices,” said Garfield.

    Expedia’s Microservices Journey

    To see real-world microservices architecture in action, take Expedia. Previously, Expedia services had existed within monoliths, which meant much duplication. Services were detrimentally tethered, meaning if a service broke you had to fix the entire monolith.

    Garfield describes how Expedia isolated its architecture into individual microservices to represent abilities such as car search, car sorting, bookings, airline search and others. While this aided elasticity and usability, the microservices journey came with issues.

    Problems in Microservice Heaven

    Expedia ran into multiple problems within their microservices journey. Though Expedia had valid business reasons to adopt microservices, “they didn’t have a plan for how to scale their CI/CD that was realistic,” expressed Garfield.

    Foremost, as the number of microservices expanded into the hundreds and thousands, standardizing CI/CD became quite difficult. The organization was using one CI/CD pipeline per service, meaning they now had to support thousands of pipelines, each connected to an individual Git repository. A microservice may also have different pipelines for production, internal use or testing environments, leading to even more duplication.

    When you scale microservices, you also encounter a new set of roadblocks related to network and storage. This became extremely evident when Expedia realized the sheer network bandwidth and related costs from running validation and integration testing on thousands of separate CI/CD pipelines.

    “The scale of automation itself is where most people have the biggest bottlenecks,” said Garfield.

    Consolidating codebases with plugins and shared libraries became a common issue. Expedia developers experienced issues with Jenkins and were forced to programmatically or manually edit each pipeline, copy and pasting code from one to the next. In short, the flow was not easy, and differing approaches between teams led to shadow IT.

    Solutions For Scaling Microservices

    To help ease large-scale microservice environments and CI/CD pipelines, Garfield recommended taking a few approaches:

    • Use a container-based pipeline: The first principle Garfield suggested is using a container-based pipeline. If a pipeline is containerized, you can run it independently with different language versions. According to Garfield, “shared libraries are not the solution,” as they create version-specific conflicts. Using a Docker image is better than shared libraries because users can self-serve images with whatever version they want.

    There are many resources on Docker Hub to ease common CI/CD steps such as building a Docker image, git clone, running unit tests, linting projects and security scanning. Using these images can help avoid wasted development effort.

    • Consolidate to a single pipeline that operates with context: Instead of managing thousands of pipelines for all your microservices, Garfield suggested you use a single malleable pipeline for all integrations and deployments. His method involves Triggers, which carry information to direct actions.

    In this setup, Triggers carry context, or metadata, allowing a pipeline to change its behavior accordingly. These Triggers could be time-based or centered around actions like a repo Git commit, or pushing a new image. When a trigger is initiated, the trigger brings in relevant dependencies to perform an action, such as cloning a repository or cloning a codebase. Further steps can then consume these unique criteria.

    Garfield demonstrated how this is accomplished in practice within the Codefresh CI platform with native Kubernetes integrations. The platform also enables you to filter and view by certain criteria; a window into commits and changes.

    Garfield acknowledged this overall strategy does mean making microservices a bit more uniform, but perhaps the ease of deployment could outweigh the development constraints.

    • Adopt canary release testing: If an organization has hundreds or thousands of microservices, spinning up each microservice to run independent tests can quickly become cost-prohibitive. As Garfield noted, “testing early becomes less useful as infrastructure complexity arises.”

    To solve this issue, teams can adopt a canary release strategy. Canary release is a practice in which new software is first released and tested among a small subgroup of users. It’s a good way to “limit the blast radius of a change that goes wrong,” said Garfield.

    Lasting Image: Pipeline Reusability

    Adopting a single container-based CI pipeline could help resolve the expanding set of issues with large-scale microservices testing and deployment. By templatizing pipelines, many microservices could abstract complexity and reuse the same modular components. Essentially, make CI/CD reusable in the same way microservices are.

  • HashiCorp Extends Consul Service Mesh Reach

    HashiCorp Extends Consul Service Mesh Reach

    HashiCorp today made available an update to its Consul service mesh that makes it easier to integrate legacy and modern applications.

    Service meshes have emerged as a framework for documenting and controlling how application services interact with one another. Most of the adoption of service meshes thus far has involved applications built using microservices. With potentially hundreds or even thousands of microservices to manage, a service mesh framework becomes essential.

    HashiCorp Consul 1.8 extends the reach of the Consul service mesh by making available additional gateway and compliance features that make it easier to integrate any service into any mesh, in addition to adding support for audit Logging and single sign-on (SSO) capabilities.

    Amith Nair, vice president of product marketing for HashiCorp, said organizations that adopt Consul can apply a service mesh to both microservices and monolithic applications. That approach also eliminates the need to deploy a service mesh such as Istio, which only works when deployed in conjunction with a Kubernetes cluster.

    In general, Nair said Consul enables IT organizations to gain the benefits of a service mesh without being required to retire existing application services or manage them in isolation from modern cloud-native applications.

    Longer-term, Nair said HashiCorp expects an ecosystem to develop around Consul as technology partners extend the core capability of a service mesh to add, for example, application firewall services.

    It’s too early to say to what degree IT organizations will embrace service meshes as a technology. However, as IT environments become more complex many enterprise IT organizations are shifting toward managing services rather than individual applications. That approach enables IT organizations to align their IT strategy more easily with specific business outcomes.

    At a time when many organizations are also trying to accelerate a transition to digital business processes in the wake of the COVID-19 pandemic, most of those digital business processes are typically a collection of loosely coupled application services that could be managed via a service mesh.

    Nair said while it’s still early in terms of adoption, most enterprise IT organizations are now at least aware of what a service mesh does and why they might need to deploy one. The challenge, of course, will be getting IT organizations to prioritize the deployment of a service mesh when many IT budgets have become suddenly constrained. It’s also not clear who inside of those IT organizations will fund service mesh projects, which benefit a variety of application projects—application owners tend not to directly fund centralized IT management services, which leaves it up to IT leaders to fund. The challenge is, most IT budget dollars are already allocated.

    In the meantime, developers will continue to embrace everything from Kubernetes to serverless computing frameworks. However, the rate at which new applications are deployed generally far exceeds the rate at which applications are retired. As such, IT organizations should expect to find themselves managing a wide array of different types of application services for many years to come.