Category: Tools

  • WSO2 Advances Microservices Gateway

    WSO2 Advances Microservices Gateway

    At the Open Source and Software Development Conference (OSCON), WSO2 this week announced it has updated an open source microservices gateway to make it possible to expose multiple microservices through a single application programming interface (API).

    Additionally, version 3.0 of the WSO2 API Microgateway now includes the ability to automatically discover microservices and transform legacy API requests into a more modern format. WSO2 also added support for the OpenAPI Specification (OAS), formerly known as Swagger, to make it easier for developers to collaborate on creating APIs, and has separated the WSO2 API Microgateway toolkit from the runtime to enable greater scalability and smoother upgrades.

    Ken Oestreich, vice president of product marketing for WSO2, said the WSO2 API Microgateway is designed to accelerate the convergence of application development and integration into a single team. As part of that effort, WSO2 has been advocating the adoption of Ballerina, a general-purpose programming language designed from the ground up to make it easier for developers to integrate distributed applications on their own. For example, Ballerina makes it possible for developers to create and embed their own micro-enterprise service bus (ESB) within a distributed application, he said.

    Those integration engines then could be deployed and updated within any DevOps processes layered on top of a continuous integration/continuous deployment (CI/CD), Oestreich added.

    A WSO2 API Microgateway is designed to boot up in less than a second and provides authentication, authorization, rate limiting, service composition, discovery, transformation and analytics capabilities. It is designed to be integrated with the WSO2 API Manager, an open source API management platform that can run on-premises or in the cloud.

    As the number of microservices being created within organizations increases thanks to the rise of containers, Oestreich noted there is now a critical need for organizations to find a lightweight approach to building and managing all the APIs required to connect thousands of microservices. WSO2 provides a flow diagram through which organizations can visually manage that process, said Oestreich. As part of its support for containers, the WS02 API Gateway provides built-in support for container orchestration tools such as Kubernetes, which makes it possible to generate artifacts that can be applied directly to Kubernetes clusters.

    Organizations of all sizes are clearly struggling these days with API management. In theory, APIs should remain stable as the software components they connect to are updated. The trouble is, each new microservice generates its own set of APIs, and before too long, organizations find themselves trying to manage thousands of APIs that are all dependent on each other. The removal of any one API might not crash an application, but it could adversely impact performance as API calls are re-routed around the application.

    It’s not all clear these days who inside most organizations is responsible for managing APIs. Developers certainly create the APIs. However, once they are deployed in a production environment, their care and feeding often pass over to an IT operations team. Regardless of whom, however, once any of those APIs break it’s not long before the entire DevOps team knows about it. The challenge now is figuring out how to make the management of all those APIs as natural an extension of a DevOps process as possible.

    — Mike Vizard

  • The Changing Role of APM in a Microservices World

    The Changing Role of APM in a Microservices World

    Microservices usage has skyrocketed. Fully 91 percent of organizations are using or have plans to use microservices and 92 percent expect to grow their use of microservices in the coming year. It is no longer if but when: 86 percent of organizations expect microservices to be the default within five years.

    With the growing use of microservices and containers, applications have become orders of magnitude more dynamic. It’s not unusual for containers or building blocks of the application to have a shelf-life of less than a week. However, what is great for application development can create challenges when it comes to monitoring ­and diagnosing performance issues in ever-changing applications. How does application performance monitoring (APM)  change to support microservices and dynamic cloud-native apps?

    More Moving Parts

    Small, specialized microservices may facilitate shorter development cycles, continuous releases and greater agility, but when deployed across dynamic cloud infrastructure, the sheer number of moving parts also makes it much more difficult to troubleshoot application performance. Highly distributed and transient containerized components need to be tracked and measured continuously, demanding a big data approach for APM tools. To be effective, monitoring containers and microservices requires high-definition visibility across all transactions, machine learning to pinpoint problems and a shift in focus to users from servers.

    High-Definition Data

    Because the dynamic, containerized environment is constantly changing, measurement data must be collected at high frequencies—think seconds rather than minutes. Collecting infrastructure performance metrics at one-minute intervals, or longer, can distort the real situation and sometimes miss entire events altogether. For example, at low definition, a pattern of recurring but brief spikes in CPU usage will either be averaged out or not register at all—but if detected would be a tell-tale sign of a systemic configuration issue. High-definition infrastructure metrics, collected at one-second intervals, are crucial for a comprehensive view of resource utilization and shared resource dependency issues.

    However, infrastructure metrics alone are not enough. Building a complete view of the operating environment calls for data from multiple sources, including application traces, system metrics, application logs and network behavior. The resulting data set is very large, necessitating big data collection methods and processes. In-line data compression, NoSQL back-ends, non-intrusive client agents and cloud scaling are foundational technologies for modern APM tools.

    Correlating Data End to End

    Big data analytics and visualizations are necessary to process APM data into human-scale patterns and events. Identifying root cause of a performance problem often involves following a transaction from end to end, through multiple containers, shared resources and downstream infrastructure dependencies. Next-generation APM tools dynamically map the flow of every single transaction, through all intermediate relationships. Machine learning and artificial intelligence, while still in their early stages, are proving essential to finding patterns and anomalies in the data, suggesting probable causes and flagging them for human investigation. Combining the best of machine and human skills results in faster problem identification, diagnosis and resolution. IT operations teams benefit with improved application performance, reduced repair times and higher uptime even in dynamic application environments.

    Putting the Focus on the End User

    Legacy APM tools tend to focus on infrastructure components and resources, monitoring the health and utilization of servers, storage and networks. Organizations today, driven by digital competition and customer satisfaction, need to concentrate on the user’s perspective. This means monitoring multiple types of user devices for health indicators and mapping each transaction to the backend system. Automatic instrumentation delivers real-time end user metrics that trigger alerts much earlier than server-side monitoring, and enables more effective prioritization. End user insights also help DevOps and product owners track feature and application adoption rates, compare performance before and after upgrades and directly relate technical issues and investments to business priorities.

    Monitoring Apps for Today and Tomorrow

    Clouds, containers and microservices require a different approach to performance monitoring that takes into account the speed, size and life cycle of application modules. Effectively watching these distributed and transitory processes demands a big data approach that can handle the scale of end-to-end transaction data in modern enterprise environments.

    Legacy APM tools that only take snapshots result in an incomplete view of application reality and lengthen problem resolution times. Instead, modern APM systems collect a complete data set, enabling DevOps to quickly resolve intermittent and complex issues that impact business productivity and user satisfaction. They augment their skills with machine learning to quickly identify anomalies and guide them to probable causes. The results are better application performance, enhanced competitiveness and perhaps most important, increased user satisfaction.

    — Gayle Levin

  • Don’t Let Your DevOps Transformation Be a Parade of Tools

    Don’t Let Your DevOps Transformation Be a Parade of Tools

    Choosing the right DevOps tools should be a careful, thoughtful process.

    On May 12, 1848, a store owner named Sam Brannan held a “one-man parade” to announce the start of the San Francisco Gold Rush. “Gold! Gold from the American River!” Brannan shouted up and down the market street in San Francisco. He held his hat in one hand and waved a bottle of gold dust in the other. San Franciscans had received false news of gold before. But by all accounts, Brannan’s performance sent residents running in search of riches. 

    Brannan had a good reason for spreading the news rather than panning for gold himself. The canny entrepreneur owned a general store that served the workers, and in the week between learning about the discovery and yelling about it in San Francisco, he’d bought all the picks and shovels in the city. Brannan’s announcement helped spur a seminal event in California’s history. As Brannan raked in money selling mining supplies, his actions also, years later, led to the coining of a famous maxim. (source)

    During a Gold Rush, Sell Shovels

    In the current age of DevOps and Agile rush of enterprises, there is a lesson to be learned from the gold rush: Don’t let your DevOps transformation become a parade of tools. While automation is critical for the success of modern ways of technology delivery and operations, the wide range of tooling choices can often lead to wrong decisions—especially well-intentioned, top down purchase of tools, duplication in toolsets and, most importantly, ignoring the voice of the teams on the ground.

    With such variety of tools available in the market today, we all have opinions regarding the tools that we would like to use. Our preferences are based on either our history of using certain tools, because we have invested time and effort to learn a tool, or partnerships your service vendors might have with tooling vendors.

    This leads to two general attitudes toward tooling adoption, with each having their own advantages and disadvantages:

    Autonomy for teams: Let teams decide the tools they feel are suitable for their context.

    The advantage is that teams can experiment and pick a tool that suits their context better. The disadvantages can, potentially, include security risks due to lack of patching and maintenance, and limited cross-team collaboration and sharing of tooling skills and know-how.

    Standardized tool suite: A centralized way of dictating tooling choices.

    The advantage is that it allows for capacity planning, integration between tools, larger pool of community for collaboration and create platforms-based solutions.The disadvantage is that this method at times prevents teams from using tools that best suit their unique needs and creation of avoidable dependencies on centralized tooling teams in the organization.

    These contrasting views lead to debates at every level for the choice of tools and, in some cases, slowing down decision-making—or even leading to the purchase of tooling licenses without input from technical teams on the ground. The decision-making process must be improved, and the need for autonomy must be balanced with standardization and optimization. Also, the two approaches of “autonomy for teams” and “standardized tool suite” do not always have to be binary and will change depending on the context of the team needs and area.

    By considering desirability, viability and feasibility of the DevOps tools, we can help achieve the balance between autonomy and alignment.

    Here are some tips to help ask the right questions:

    Desirability

    • Do teams want this? or is this a solution chasing a problem?
    • Do you anticipate that teams will need this in the near future?
    • Does this help improve team productivity and effectiveness?

     Viability

    • Does this make commercial sense?
    • Have we considered maintenance costs and total cost of ownership?
    • Do we have existing license arrangements with the tooling vendors?
    • Do we have comparable tools already in use and that can do the job?
    • Do we need to purchase licenses throughout the enterprise?
    • Are there any open source alternatives?

    Feasibility

    • Can we implement this in the enterprise IT landscape?
    • Have we considered the ease of setup and configuration of the tool?
    • Does it scale across the enterprise? Does it have to scale across the enterprise?

    — Aditya Vadaganadam

  • DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and cloud computing are not mutually exclusive, though their relationship has often been uncertain and confusing from a layman’s perspective. While cloud computing relates to technology and services, DevOps is more about processes and process improvement. However, both DevOps and cloud computing are vital in every organization’s journey toward an effective digital transformation.

    Cloud-centric DevOps Automation

    Cloud computing’s centralized nature enables a standard and centralized platform for DevOps automation. Using a cloud platform resolves issues in centralized software deployment caused by the distributed nature of enterprise systems.

    DevOps objectives including continuous integration (CI) and continuous delivery (CD) are supported by most of the private and public cloud service providers. This ensures centralized governance and control, in addition to reducing the costs associated with DevOps automation on-premises. DevOps utilizes orchestration systems that can proactively monitor the cloud data sets and application workloads. End-to-end automation is a prerequisite for deriving the full advantage from the cloud.

    By expanding the concept of continuous improvement to cloud-based platforms, DevOps ensures lesser system vulnerabilities and greater security.

    DevOps Best Practices for Effective Cloud-Based Computing

    DevOps provides several core capabilities that assist organizations in effectively handling cloud challenges. These include:

    • Infrastructure as Code (IAC): IAC comprises the provisioning of servers and installation of application code, the core components of the system architecture.
    • Automated Application Deployments: DevOps practices facilitate the creation of a fully automated application deployment pipeline that is of great importance in the development life cycle.
    • Application Lifecycle Management (ALM): DevOps principles such as continuous integration and delivery help in effective ALM in the cloud.
    • Continuous Quality Assurance (QA) and Testing: DevOps capabilities address the challenges for QA and testing in the cloud by provisioning multiple test environments using cloud-based resources that result in enhanced quality and productivity.
    • Knowledge-Sharing with the Cloud Provider: DevOps promotes the concept of knowledge sharing between organizations and SMEs of the cloud service providers throughout the application life cycle using online communities that are focused on fostering communication and collaboration, thereby ensuring that most risks are mitigated effectively.

    The Significance of Cloud Computing vis-á-vis DevOps

    Cloud computing complements DevOps in several ways. The application-specific infrastructure in the cloud enables developers to own more components easily and enhance their productivity and efficiency. It allows developers to create the development environments quickly without the need for IT operations to provision resources and infrastructure.

    Cloud computing ensures flexible IT infrastructure in addition to enabling greater business agility. It propels IT transformation by helping organizations in streamlining and embedding DevOps processes.

    DevOps tools and services eliminate human error and help in establishing repeatability by automating and streamlining the process of building and managing code.

    IT Transformation Enabled by DevOps with Cloud Technology

    Cloud computing coupled with DevOps ensures that scalability becomes an integral part of application development, thereby contributing to reduced infrastructure costs and increased global reach.

    Cloud-based operations increase the availability and failover ability of applications in addition to eliminating downtime, which leads to improved business reliability and rise in customer satisfaction.

    DevOps automation and IAC help in reducing the complexity of the cloud and improving system maintenance. Additionally, the automated repeatable processes increase security controls. Process streamlining and faster access to the development environments ensure improved product time to market.

    In Conclusion

    By realizing the importance and prioritizing the usage of DevOps in the cloud, organizations can derive a huge number of potential benefits including enhanced agility and reduced operational costs.

    — Veritis

  • NGINX Delivers New Products to Manage Microservices

    NGINX Delivers New Products to Manage Microservices

    At its annual user conference in Portland, Oregon, in September, NGINX delivered releases focusing on the application platform market and support of delivering microservices architectures:

    • NGINX Plus, an application delivery controller that combines a load balancer, content cache and web server.
    • NGINX Controller, a centralized management and monitoring platform for NGINX Plus, which orchestrates the delivery of applications across multiple environments, enabling companies to continuously deploy and update applications using tested and proven policies.
    • NGINX Unit, a multi-language server for applications, designed to work in highly dynamic environments. It features a full REST API that can be fully automated and used to deploy new application versions with no service disruption. It currently supports PHP, Python and Go with more language support coming soon.
    • The NGINX Web Application Firewall (WAF), powered by ModSecurity, which protects web applications against various Layer 7 attacks and provides DDoS mitigation, real-time blacklisting and audit logging.

    In addition to launching the NGINX Application Platform, the company has added the ability to use NGINX Plus as a Kubernetes Ingress Controller. Based on the open-source NGINX Ingress Controller for Kubernetes, this new feature enables the deployment of applications within Kubernetes and Red Hat OpenShift anywhere across a cluster so they can be reached by outside traffic.

    While these products combine to deliver a complete and manageable microservices solution, the most interesting of these is NGINX Unit. According to Owen Garrett, head of products, the complement of tools facilitates management of both north/south and east/west traffic for cloud-native applications. It’s small, lightweight, fast, polygot-enabled and programmable through an API and works with other Unit instances to deliver a service mesh.

    Key features of Unit that should be of particular interest to businesses deploying microservices relate to the ability to foster continuous delivery. For example, when the router accepts new configurations from the Controller process, the worker threads start to handle new incoming connections with the new configuration, while old connections can continue to be processed by the threads according to the previous configuration. That is: Router worker threads can work simultaneously with several generations of configurations.

    Additionally, Unit uses interprocess memory to communicate with the applications, thus allowing the Unit to provide greater agility in routing of HTTP requests. So, rather than forcing the application to directly listen, they can delegate network handling to the service mesh providing for increased scalability. They accept the clients’ requests, pass the requests to the application processes, get responses back from the applications and send the responses back to the clients. Each worker thread polls epoll or kqueue and can asynchronously work with thousands of simultaneous connections.

    — Alan Shimel