devopsy.kinsta.cloud

Tag: microservices

  • The Purpose of Microservice Architecture

    The Purpose of Microservice Architecture

    Microservice is an architectural style that can be implemented during complex application development within an organization. The implementation of this architecture allows the application being developed to be highly maintainable and testable, loose, independent during deployment and also strongly organized around business capabilities. In another way, the microservice architecture can be explained quite easily. It is a software development technique that allows for the structuring of an application. The structure of the application being considered will be that of a set of coupled services.

    Any application developed using the microservice architecture is easy to understand, develop and test. More so, the application will have a sort of rigid attitude to degradation in the long run. This is due to the concept adopted during design.

    The design of the microservice architecture ensures that applications are separated into smaller services, states, etc., until they become fine-grained and light in weight. Therefore, the modularity achieved encourages the adoption of methodologies that will allow for the division of labor. These methodologies will aid in the concurrent design, development and testing of the sub-services independently.

    While this architecture is suited to certain scenarios, it (like every other architectural style) has its demerits. Microservice experts advise on the study of the architectural platform before adoption. The implementation of the microservice architecture can be affected by a number of programming languages.

    Within the context of this article, I discuss the purpose of the microservice architecture, and also examine the upside and the reasons why they should be learnt and implemented. I also take a look at particular niches that allow the use of microservice architectures and why they use it.

    Architecture, Examples and Types of Microservices

    The microservice architecture is a major decomposition of the monolithic architectural method. The monolithic architecture had applications developed from the top to bottom and also had the entire development process run as a single unit. The microservice architecture works in contrast to this by enabling modularization. The core of the microservice architecture has requirements that are intensified and made possible by the separation of the primary task into smaller services, in which one service represents just a requirement, function or need.

    Examples of microservice architectures can be found in airline service scenario. If we pick out the flight booking component, we could find out that this primary task could be separated into inventory adjustment, seat allocation, fare calculation, timetable lookup, reward management and customer update.

    Applying Microservices

    Research has it that the majority of the companies that make use of microservices are quite on the high side. This majority includes organizations such as Netflix, eBay, Amazon, PayPal, Twitter, The Guardian, etc. This list also includes the United States Government Digital Service.

    The application of microservices can work with a number of technologies but a number of researches attribute effective usage of this architecture with the cloud environment and the DevOps environment as well. These tools and environments help to manage the operational complexities that affect the swift functionality of the architecture.

    Why Do They Use It?

    Most of the organizations that make use of the microservice architecture did transcend from the monolithic method. This is mostly because the method offers organizations the ability to decompose primary applications into smaller composed pieces. These pieces can then be built independently (which is easier) and also maintained independently as well. Developed pieces have the ability to communicate with each other and work together as well.

    The adoption of microservice architecture provides the management of an organization and everyone involved in the development of the application with a decentralized approach towards building the software. This approach breaks the development process into a series of deploy, rebuild and redeploy.

    The choice of a microservice architecture also grants organizations the ability to implement variant strategies, tools, techniques, etc., for services that are involved. Studies show that organizations that implement this architecture have a high proficiency rating. This is due to the usability of the architecture in independency, deployment, replacement, etc.

    The architecture encourages easy debugging of errors and detection of faults in general. When an error is spotted, the segment from which it originated can be easily traced and the fault can be found shortly after. This, as explained earlier, is because primary tasks are separated into smaller services. Each service can then be fine-grained to simple state. Before the simple state is attained, it is also possible that the service can be separated into a smaller group of services. This option helps the development team actualize a major concept within this architecture, which makes sure that a service handles just one task. Also, the architecture allows for the adoption of management techniques that assist the organization. These management techniques include options such as change management process, continuous software development processes, problem and incident management techniques, etc.

    Benefits to Using Microservices

    The benefits to using the microservice architecture include:

    1. The actualization of scalability when considering customer-focused services.
    2. Independent deployment of services.
    3. The ability to work with more than one development tool (such as  programming languages).
    4. Easing the modularization of tasks within the project as a whole due to the modularization of the application being developed.
    5. Support for a wide range of platforms and devices such as web, mobile, internet of things, etc.

    — Subramonian

  • 5 DevOps Terms That We All Use, Yet No One Can Define

    5 DevOps Terms That We All Use, Yet No One Can Define

    I’m all for DevOps. Sometimes, however, I have a hard time talking about DevOps. The reason is because many of the key terms related to DevOps lack clear and precise definitions.

    Let me explain …

    DevOps is such a big deal that it has bred its very own lexicon. Search Google for “DevOps terms,” and you’ll find a slew of “dictionaries” and “glossaries” dedicated to defining the various terms that go hand in hand with DevOps.

    Yet despite these resources, some deep ambiguities remain regarding the actual meaning of various terms that you hear frequently in DevOps-centric conversations. Let me walk through some of the biggest.

    Continuous

    DevOps is all about continuous this and continuous that. Continuous integration. Continuous delivery. Continuous deployment.

    To me, the problem with the word “continuous” in this context is that it lacks an exact meaning. No one is integrating, delivering or deploying software in a literally continuous fashion. That would mean having zero delays between different releases, which is not the case. Even organizations that do CI/CD really well manage deliveries and deployments of only once per day or so.

    Maybe instead of “continuous,” we should just say something like “fast.” Because that’s what “continuous” really means in most cases.

    CI/CD

    Speaking of CI/CD, that’s another term that is ripe with ambiguity. It’s clear enough what “CI” stands for (continuous integration). But does the “CD” stand for “continuous delivery,” “continuous deployment” or both? Or does it not matter?

    Moreover, does a your application delivery process qualify as a CI/CD pipeline simply by including a continuous integration server (to do the CI) and some kind of automated deployment tool (to cover the CD side of things)? Or does a CI/CD pipeline also necessarily include build and test automation? I think most people would say the latter, but the term itself does not imply that.

    Microservices

    Microservices are all the rage in the era of DevOps. Depending on how you define a microservice, however, they have been all the rage for decades, long before anyone was talking about DevOps.

    The idea of distributing applications into multiple services is not new. That’s what SOA was all about in the 2000s. Going back further, there were microkernels, a concept popular in the 1980s. In microkernel architectures, the operating system kernel runs as a set of distinct services, rather than as a monolith.

    The question, then, is what makes a microservice, or a microservices architecture, different from other types of distributed, service-based architectures. Maybe it’s the size of the service, but there’s no official definition of what distinguishes a microservice from a non-microservice.

    Agile

    It is often said that DevOps builds upon the principles of agile software development. Those principles were defined, at a high level, in the early 2000s and spelled out in the “Manifesto for Agile Software Development.”

    It’s clear enough what agile means, but I’ve long struggled to piece together the exact relationship between agile and DevOps. Is DevOps “agile applied beyond the software team,” as one DevOps company puts it? Or are agile and DevOps distinct practices that just happen to have similar goals?

    It’s hard to say, because there is little consensus about what exactly “agile” means in the context of DevOps.

    DevOps

    Last but not least is “DevOps” itself. Different people have defined DevOps in very different ways. AWS says it is “the combination of cultural philosophies, practices, and tools.” Other definitions focus on philosophy, and leave tools and specific practices mostly out of the picture.

    Blurring the definition of DevOps further is the fact that virtually every tech company in the world calls itself a DevOps company today, with little concern for how, specifically, its products or services meet that nomenclature.

    What does DevOps really mean? I don’t think we’ll ever have a singular answer to that question.

    Conclusion

    In fact, I don’t think there will ever be clear definitions for any of the terms I’ve listed above. I’m not suggesting there should be.

    But I do think it would be helpful to the DevOps community as a whole to recognize the ambiguity in many of these terms. We use these words as if everyone knows what they mean, but the reality is that that is often not the case. If you want to use terms like “continuous” or “agile,” do so, but remember to clarify what those terms mean to you, because you can’t assume that they mean the same thing to others.

    — Chris Tozzi

  • Kubernetes Adoption: Are You Ready?

    Kubernetes Adoption: Are You Ready?

    Enterprises are rapidly embracing a cloud-first strategy and microservices play a pivotal role in this journey. But enterprises are achieving various levels of success, measured by many factors includingmaturity of DevOps in the enterprise, ability to identify the right candidates for microservices, selecting the appropriate container management platform, adequate tooling and, finally, cultural shift in design thinking.

    As there is plenty of material around microservices adoption and strategy, this article focuses on the container management ecosystem, which plays a critical role in the success of microservices adoption. Today, Kubernetes has become the de facto platform for container orchestration. Most public cloud providers offer Kubernetes as a service in some form to abstract the complexities of managing Kubernetes as a platform.

    Currently, we see three broad patterns of how enterprises are adopting Kubernetes within their organizations.

    Pattern 1: Kubernetes as a Managed Service

    While Kubernetes makes container management somewhat simple, it is still a complex beast to understand and manage as a platform. Enterprises that have already embarked on a cloud strategy find it easy to test the unchartered waters of Kubernetes by leveraging Kubernetes-as-a-service provided by their cloud providers. It enables them to understand the impact of Kubernetes on their respective application architecture strategy and identify the gaps in their systems (such as the maturity of DevOps management, security management and release management) as well as their monitoring capabilities.

    Pattern 2: Kubernetes as a Turnkey Solution

    Certain enterprises driven by industry regulations and are technology-focused (with considerable experience in other container technology solutions), have shown interest in setting up Kubernetes as part of a private cloud or on–premises with a view to avoid vendor lock-in and limited control associated with managed Kubernetes. There are many such turnkey solutions out there to choose from.

    Pattern 3: Self-hosted Kubernetes Platform

    This category is small compared to the other two categories. However, there are a few enterprises that fully embrace the open source software development model and contribute to Kubernetes community. There are tools and frameworks that can enable the enterprises to setup and manage Kubernetes on their own.

    There are advantages and constraints in adopting any of the above approaches. The decision regarding which strategy to choose depends on the maturity of the enterprise and their business strategy.

    Challenges in Adoption

    Some of the key challenges to be considered, irrespective of the adoption pattern selected, include:

    1. Namespace management: Namespaces play a key role in managing the isolation across application domains and environments, providing controlled management of resources and user management. Bounded contexts can be linked with namespace definitions and standards. It is important to define proper naming guidelines to drive namespace management across clusters.
    2. Resource management: It is necessary to define resource utilization (resource quota) guidelines to ensure the containerized applications co-exist without being eliminated due to resource violations at runtime.
    3. Policy management: It is critical to define appropriate policies including cluster access controls, service access controls, resource utilization controls and secret access controls.
    4. Audit and compliance: It is important to audit the platform for patch levels, secret stores, compliance against the security vulnerabilities, encryption of secret stores, storage volumes, cluster policies, role binding policies and user management controls.
    5. Chaos testing your platform: It is necessary to subject the platform to chaos testing to ensure the robustness of the cluster. It also helps to test the stability of the containerized applications and the impact of crashing these containers. It will also provide vital information about how the platform behaves during high loads or when resources are unavailable for the platform.
    6. Managing the deployment manifests: Kubernetes follows declaration-based management, which means that every object or resource instruction is described through declarative manifests. This leads to versioning complexities, prone to human errors and data corruptions. It is necessary to leverage tools or create custom utilities to manage these manifests.
    7. Observability of the platform: While Kubernetes provides various mechanisms to monitor its own internal components, it does not recommend a standard monitoring approach. It is necessary to introduce well-defined health management standards while designing the microservices. Include appropriate probes for liveness and readiness probes in every containerized application deployed on Kubernetes cluster. Integrate the probe-generated metrics and platform-generated metrics with an external monitoring platform to have comprehensive observability of the cluster.
    8. Continuous deployment of services: It is not recommended to use kubectl-based deployments in a large-scale production setup. Instead, use some of the established open source frameworks specifically built for Kubernetes (such as Helm or JenkinsX) to manage seamless deployments.
    9. Archiving and backup: Kubernetes uses etcd as its internal metadata management store to manage the objects across clusters. It is necessary to define a backup strategy for etcd and any other dependent persistent stores used within the Kubernetes clusters.
    10. Container security management: Kubernetes deploys the applications by downloading the respective images from a pre-defined image repository. It is the responsibility of the repository ecosystem to ensure the image provenance of the images being deployed. Continuous security must be included as part of DevOps pipeline to ensure containers are well-managed.
    11. Service mesh support: Service mesh plays a critical role in streamlining the service to service communication. It abstracts the service level access controls and security management between services through externalized policies. It also provides routing and load balancing features. It is necessary to choose an appropriate service mesh that is compatible with the Kubernetes cluster as well as the underlying infrastructure.

    Conclusion

    Kubernetes makes the container operational aspects simpler, but it requires a methodical approach and best practices to ensure smooth maintainability, as well as seamless developer interaction. For any enterprise which are in a transition journey toward adopting Kubernetes, it is imperative to have a strategy for Kubernetes adoption to ensure success.

    — Sreekanth Nyamars

  • Wavefront Provides Map for Microservices

    Wavefront Provides Map for Microservices

    VMware announced it is adding a service mapping capability to the Wavefront 3D Observability platform it provides with the Wavefront by VMware monitoring tools.

    Stela Udovicic, senior director of product marketing for Wavefront, said Wavefront Service Maps will make it easier for IT organizations to visualize what will soon be thousands of microservices running highly distributed computing environments, including those based on containers running on Docker Engine, connected via service meshes such as Istio or spanning proxy servers such as Envoy.

    Capabilities provided by Wavefront Service Maps include packaged visualization of request flows with a map of service dependencies, built-in tracking of health metrics and view into individual traces to pinpoint performance bottlenecks.

    Accessed as a set of software-as-a-service (Saas) applications, Wavefront by VMware relies on an agentless approach to monitoring that supports all the major public clouds along with providing integrations with platforms such as Kubernetes, GitHub, Slack, PagerDuty, Kafka and Pivotal Application Service.

    Udovicic said by making it easier to visually identify and troubleshoot microservices, IT organizations should be able to accelerate their transition to modern cloud-native applications. Building and deploying a single application based on microservices is complicated enough. Trying to support hundreds of those applications is simply too daunting without the ability to visualize all the interdependencies between those services. Troubleshooting any issue then becomes easier because Wavefront Service Maps is designed to enable DevOps teams to drill down to the traces being employed to monitor the application, she said.

    Earlier this year, Wavefront added support for distributed tracing and machine learning algorithms that also make it easier to identify anomalies within a microservices-based application.

    In terms of adoption of cloud-native applications, Udovicic said there are basically two classes. The first are early adopters who are already highly committed to developing cloud-native applications. The bulk of the enterprise IT community, however, is still in the early stages of building and deploying these types of applications, said Udovicic.

    There’s naturally a high correlation between organizations that have adopted cloud-native application development using microservices aggressively and those that have implemented best DevOps practices. In fact, one of the benefits of a visualization tool is that it makes it easier to bring new members on to those teams. Rather than having to piece together what is occurring in the environment, a new member of a DevOps team can visually inspect each microservice they might be responsible for managing.

    It may be a while before DevOps processes become the dominant default method for managing IT. But as DevOps tools become easier to use, the number of DevOps practitioners should increase steadily. Arguably, one of the reasons DevOps adoption is not as far along as it might be is that the learning curve is still too steep. But as visualization capabilities gets added to the analytics frameworks baked into those tools, it’s now only a matter of time before the number of IT professionals that might be intimidated by DevOps processes starts to decline steadily.

    — Mike Vizard

  • Keeping NoOps From Going Rogue

    Keeping NoOps From Going Rogue

    “We’re NoOps—everything is in the cloud and we have no infrastructure to manage.” Before running that victory lap and shifting everyone to the dev side, consider several NoOps risks carefully. I’m really thinking about teams using all-SaaS stacks, especially in martech, edtech and other areas. However, the rise in microservices and serverless means more teams are leaning toward NoOps. At least a few people on your team should always watch for rogue issues on the ops side of the equation.

    Locked-in Vendors

    Risk: Cloud-based tools in the same category rarely have the same functionality. Once one is selected, you’re committed to its specific features. Moving away from a tool may mean dropping a popular application feature or changing workflow with coding to recreate functionality.

    Mitigation: Evaluate unique features and customized data fields carefully before use. Solving data format differences is relatively easy for common fields. Look for tools with well-documented APIs and integrations or connector support for analytics. If there are no integrations out there, that’s a red flag.

    Ghosting

    Risk: Lock-in becomes a big problem if the vendor ghosts. SaaS startups often meet one of two fates: they are acquired or they crash and burn. A tool critical to your workflow may disappear overnight. In the acquisition scenario, you may have some time and support in migrating from your tool to its successor.

    Mitigation: Always have a Plan B for every cloud-based tool in your stack. Competitors are introducing new tools frequently. A trade study done two years ago may be completely obsolete on today’s fast-moving landscape. Proactive migration to newer solutions may reduce vendor risk and improve features.

    Limited Observability

    Risk: Overheard in a conference recently—Those who develop the code are more motivated to build in useful observability for those in operations if those folks are the same team. In NoOps, that’s not in play. If a cloud-based tool in your stack is down frequently or providing strange results, it may be very difficult to tell what is happening. Observability is often replaced by faith that the SaaS vendor has done its job and you aren’t experiencing a corner case it hasn’t tested.

    Mitigation: Observability and monitoring aren’t the same, but when you don’t have observability inside SaaS tools, monitoring helps. Application performance management (APM) tools are emerging with new ways to build instrumentation around microservices. Create test cases with synthetic data to check your functionality—you’ll need these to provide evidence for the vendor in any bug report.

    Unoptimized Workloads

    Risk: You’re also often at the mercy of the SaaS vendor when it comes to speed of results. It’s a common tripping point to pilot a SaaS workflow with a few users and test cases, and then find out it doesn’t scale when everyone is brought in.

    Mitigation: This is one the biggest NoOps risks where ops expertise pays off. Where is the problem, exactly? Application problems may be candidates for workload acceleration—such as running on a GPU (or FPGA) enabled cloud instance. Reporting problems may be better-suited for an analytics tool, which can be run offline with extracted data.

    Tangled Analytics

    Risk: Every SaaS tool reports different metrics in different ways. Worse, users in a multi-cloud environment face learning and visiting multiple applications to look at data. Different applications report similar facts using different terms. As the tool stack and data sets grow, it takes longer and longer to analyze data.

    Mitigation: Dashboards pay off early with one destination for data across the stack. Earlier, I mentioned the need for integrations or connectors—this should be a requirement for tool selection, both in the stack and the analytics tool. Deciding on which KPIs to track in the dashboard also focuses conversation and minimizes digging.

    Closing NoOps Risks

    There’s also the big topic of multi-cloud security and compliance, probably worth a series of posts by themselves. An Ops team working proactively in tool selection can comprehend many security risks before committing to tools and exposure. More value unfolds over time, as the security posture evolves with discovery of new threats.

    The tech pendulum is always swinging. For many organizations, NoOps swings the pendulum a bit too far from DevOps and leaves risks open. A better philosophy is MinOps, where a small team is deployed, watching for and even anticipating problems.

    I’d be interested to hear if you’ve tried NoOps and been successful over time, or if you reverted to a MinOps approach.

    — Don Dingee

  • F5 Networks Acquires NGINX to Meld NetOps with DevOps

    F5 Networks Acquires NGINX to Meld NetOps with DevOps

    As part of an effort to better align DevOps and network operations (NetOps), F5 Networks plans to acquire NGINX, a provider of widely employed open source loading balancing software.

    The two companies revealed in a call with financial analysts that the primary goal of the $760 million deal is to meld the two companies’ combined expertise to develop application delivery controllers (ADCs) that are optimized for modern applications based on microservices.

    F5 Networks CEO François Locoh-Donou said F5 Network plans to continue operating NGINX as an independent brand in addition to maintaining support for the NGINX open source community. NGINX CEO Gus Robertson will become general manager of the NGINX business unit. NGINX founders Igor Sysoev and Maxim Konovalov also plan to stay on.

    Locoh-Donou also disclosed that while NGINX software is employed today at more than 375 million sites, the company only generated $26 million in revenue in 2018, mostly by providing commercial support to enterprise customers. F5 Networks will move to combine investments both companies have been making in containers to deliver a next-generation ADC optimized for microservices-based applications spanning multi-cloud computing environments, he said.

    As part of that strategy, however, both companies will need to come to terms with Envoy, an open source load balancing project led by the Cloud Native Computing Foundation (CNCF). Envoy is already providing the foundation for multiple service mesh projects that make load balancing a feature of a higher-level mechanism for managing services running on a Kubernetes cluster. Obviously, F5 Networks hopes to fulfill an opportunity to manage multiple instances of service meshes running on multiple Kubernetes clusters that.

    In fact, Locoh-Donou cited industry research that forecasts by 2022 there will be more than 198 million workloads running on some form of a microservices-based architecture. In contrast, 44 million workloads are expected to be running on legacy platforms.

    Locoh-Donou said F5 Networks also expects to leverage NGINX to expand its presence in application programming interface (API) management and associated web application services, which he noted collectively represent multibillion-dollar market opportunities.

    The decision to acquire NGINX reflects the inevitable melding of NetOps and DevOps, he added, noting that inconsistent approaches to managing application service across emerging microservices-based environments are a recipe for creating unstable IT environments.

    While it’s still a little too early to determine to what degree NetOps will be subsumed into DevOps processes, Locoh-Donou said F5 Networks plans to advance adoption of NGINX software by educating its core base of NetOps administrators on how microservices applications are deployed across extended networks and the rigors of the DevOps processes required to manage them.

    Both F5 Network and NGINX made a name for themselves by interconnecting IT environments made up largely of virtual machines. While virtual machines are not going away anytime soon, so-called cloud-native applications built using containers running on Kubernetes clusters require a different approach to delivering infrastructure services. The challenge facing the combined company is finding a way to deliver those services in a way DevOps teams want to consume.

    — Mike Vizard

  • Enhance DevOps Experience with AWS Smart Tools

    Enhance DevOps Experience with AWS Smart Tools

    DevOps has become the champion of business operations by fostering collaboration between disparate teams, providing a common work framework and paving way for continuous delivery that greatly boosted software development.

    Amazon Web Services (AWS) has become a leading provider of DevOps tools and services and has been instrumental in taking this experience to a higher level.

    So how does AWS elevate the DevOps experience?

    Automation

    DevOps not only eliminates the cultural disparities between two different environments but also eases the software development process by automating its tasks. This has made maintaining and looking after large-scale complex environments easier.

    Earlier, implementing automation in cloud environments was a painstaking process and was similar to implementation/usage in physical or virtual infrastructures. Today, however, leading cloud services providers offer DevOps automation tools as a part of their feature package, making automation a breeze.

    Continuous Integration and Delivery

    AWS CI/CD tools make building, testing and deploying application source—or just securely storing it—simple and organized.

    Continuous Integration and Delivery with AWS DevOps

    • AWS CodePipeline: This is a continuous integration/delivery tool that builds, tests and deploys code in the event of a code change. AWS CodePipeline helps developers introduce code quickly and reliably into the software life cycle.
    • AWS CodeBuild: AWS CodeBuild is a fully managed build service that compiles source code, runs tests and produces deployable software packages that are ready for use. CodeBuild is expandable and processes multiple builds simultaneously, propelling the purpose of continuous integration and delivery.
    • AWS CodeDeploy: AWS CodeDeploy automates code deployments to instances or on-premises servers. This tool helps users to release new features rapidly, avoid downtime during application deployment and manages updates easily.

      Special Features:

      • Automatic deployment
      • Integration with third-party tools
      • Centralized management
      • Integration with other AWS services
    • AWS CodeStar: AWS CodeStar helps users to rapidly develop, build and deploy applications while providing them with a common interface for managing software development activities. It allows users to set up their continuous delivery tool-chain in minutes for faster code release.

    Microservices

    Microservices allows users to build and deploy microservices architecture with the help of containers or serverless computing.

    • Amazon Elastic Container Service: Amazon EC2 services enables users to manage large groups of containerized applications with the help of Docker containers.
    • AWS Lambda: AWS Lambda relieves users from the burden of constantly administering and managing the system while running code for virtually any type of application or back-end service. This Amazon service just requires developers to upload code after, which the system takes care of running and scaling code with high availability.

    Platform as a Service

    • AWS Elastic Beanstalk: AWS Elastic Beanstalk is used to deploy and scale web applications and services developed with Docker, Java and Python on servers such as Nginx. All users have to do is upload the code and the service will handle deployment, including capacity provisioning, load balancing, auto-scaling and app health monitoring.Special Features:
      • Quick Deployment
      • Integration with other AWS Services
      • Application Health Monitoring
      • Easy Access to Application and System Logs
      • Customized Software and Applications

    Infrastructure as Code

    • Chef: This is an infrastructure automation framework that enables easy configuration, deploying and management of servers and applications on a cloud, physical or virtual environment. It sets up the infrastructure by using recipes.
    • Puppet: It can be tedious to tend to each server individually should you need to make configuration and content changes to multiple servers. In such a scenario, Puppet helps to set up each server as an agent that relays information to the AWS Puppet Master Machine about any changes to be executed on that server, paving way for uniformity across all servers.
    • Ansible: Ansible is another configuration management, software provisioning and application deployment tool. Designed for multi-tier deployments, Ansible enables continuous delivery. It designs your IT infrastructure by describing how all your systems can work as a network.

    Amazon Web Services has a number of DevOps tools, all designed to help professionals work more efficiently in the AWS cloud environment. Are you using the AWS tools? If so, what are your thoughts about them? Let us know your thoughts in the comments section below.

    — Veritis

  • Cisco Opens IoT Development Center

    Cisco Opens IoT Development Center

    Cisco Systems this week launched an IoT Dev Center as part of an effort to foster development of a new generation of applications that will be deployed at the network edge.

    Announced at the Cisco Live EMEA event, the IoT Dev Center provides access to sandboxes and tutorials for building highly distributed IoT applications that Cisco envisions will be deployed directly on top of Cisco routers and switches. To facilitate that effort, Cisco also launched a series of ruggedized switches and routers, which, in addition to usingCisco ASICs for processing network traffic, can be configured to include x86 processors that enable low-latency applications to be deployed at the edge.

    The Cisco IoT Dev Center also provides access to a DevNet Ecosystem Exchange, through which organizations will be able to discover IoT applications optimized for Cisco infrastructure.

    Susie Wee, senior vice president for the DevNet community at Cisco, said the IoT Dev Center is an extension of the company’s ongoing efforts to build a DevOps community around Cisco infrastructure. From Cisco’s perspective, IoT represents an instance of edge computing.

    Cisco is attempting to extend its current dominance over networking infrastructure to include both networking gear for IoT environments and two-node hyperconverged infrastructure (HCI) platforms intended to be deployed at the network edge. Each of those systems will be connected via the Cisco Application-Centric Infrastructure (ACI) software-defined network (SDN), which Cisco says enables intent-based networking when infused with advanced analytics.

    Cisco claims it already has 40,000 customers using some element of its portfolio to drive an IoT application. As that ecosystem continues to evolve, Wee said it’s apparent that both operational technology (OT) teams, which historically have been responsible for embedded systems, and enterprise IT teams will need to embrace best DevOps practices to deploy, manage and update IoT applications. While embedded systems deployed by OT teams were not frequently updated, IoT applications will take advantage of containers and other microservices-based technologies to add new functionality more frequently and, when required, update systems to remediate potential vulnerabilities. By the end of the decade, many of those applications will be connected via 5G wireless networks that will provide enough bandwidth to make continuously updating edge applications much more practical than it is today.

    Less clear going forward is the degree to which networking teams will become part of a larger DevOps teams. As more applications get deployed on switches and routers at the edge, it’s obvious networking teams will play a critical role. The issue is to what degree. In many cases, networking teams will attempt to provide developers with access to a defined set of resources they can access via a self-service portal. But there are also likely to be instances when developers will want programmatic control over network resources that can be invoked via application programming interfaces (APIs).

    Naturally, Cisco is not the only networking vendor with similar edge computing ambitions. But while most IoT initiatives remain relative nascent, the next major battle for control over the network edge is more likely be determined by the sophistication of the processes enabled as it is the core underlying infrastructure.

    — Mike Vizard

  • Salt Security Unveils Platform to Secure APIs

    Salt Security Unveils Platform to Secure APIs

    Salt Security, fresh off raising an additional $10 million in funding, announced a platform that promises to advance the state of DevSecOps by making it possible to detect when application programming interfaces (APIs) are being probed by cybercriminals looking for weaknesses to exploit.

    Salt Security CEO Roey Eliyahu said the Salt Security API Protection Platform employs machine learning algorithms to first establish a baseline for how APIs are being invoked across an IT environment. The software-as-a-service (SaaS) platform then monitors activity to surface any anomalous behavior indicative of cybercriminals engaging in reconnaissance of API traffic flows, he said.

    Armed with that analytics, DevOps teams can then prioritize fixes to any potential security hole cybercriminals might be able to exploit. That approach advances DevSecOps because the Salt Security technology makes it possible to feed requests to address those security issues directly into a continuous integration/continuous deployment (CI/CD) platform—critical, he said, because all too often developers are unclear regarding what cybersecurity professionals are asking them to fix whenever a cybersecurity issue arises.

    Eliyahu noted that, in today’s business environment, security has become a major concern. According to the Open Web Application Security Project (OWASP), nine of the top 10 vulnerabilities in its current Top 10 report include an API component. Insecure APIs were ranked as the third most severe threat to cloud computing in 2018 by the Cloud Security Alliance (CSA), and Gartner predicts that by 2022 API abuses will be the most frequent attack vector resulting in data breaches for enterprise web applications.

    The challenge organizations face is each API is unique to each application and the organization that builds them, which means each has unique logic and, by extension unique vulnerabilities, said Eliyahu. Existing cybersecurity tools lack granular understanding of these because they are designed to protect organizations from known attacks. Attacks that target API logic go unnoticed by these tools because they appear to be authenticated use cases, and then employ subtle methods to probe each for unique vulnerabilities, he noted.

    To thwart those attacks, the Salt Security technology automatically discovers all APIs and associated functionality, said Eliyahu. That’s important because it’s not uncommon for organizations to lose track of the many that might have been exposed over the course of an application’s lifetime.

    APIs in general are often overlooked because much of the focus in any organization tends to be on business logic. But as the number of applications and services continue to proliferate across the enterprise, the number of APIs being exposed has increased dramatically. Those numbers will increase more as organizations embrace microservices to build applications that are more easily updated.

    The issue, of course, is how to secure APIs that often are developed and maintained by teams that weren’t involved in the integration of the original application. Because of that issue, API management has emerged as a discipline unto itself within many organizations. The challenge now is finding a way to ensure those APIs are employed as intended, versus becoming an avenue for data exfiltration that no one is aware of until it’s long too late.

    — 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