devopsy.kinsta.cloud

Tag: networking

  • Enfabrica Makes Cloud Networking Performance Advances

    Enfabrica Makes Cloud Networking Performance Advances

    Enfabrica Corp. today emerged from stealth at the MemCon conference to launch a class of processors for networking in cloud computing environments that are optimized for moving data between CPUs, graphical processor units (GPUs), accelerators and memory.

    Enfabrica CEO Rochan Sankar said the Accelerated Compute Fabric (ACF) enables scalable, streaming, multi-terabit-per-second movement of data in a way that also reduces the total cost of cloud networking. That’s critical as the amount of data being generated by applications infused with artificial intelligence (AI) capabilities that require access to larger amounts of data continues to increase, he added.

    At the same time, DevOps workflows will need to evolve as it becomes possible to compose AI fabrics of compute, memory and network resources capable of scaling to tens of thousands of nodes versus relying on top-of-rack network switches, network interface cards (NICs), PCIe switches and CPU-controlled DRAM that creates too many bottlenecks when moving large amounts of data.

    Enfabrica’s first chip, the Accelerated Compute Fabric Switch (ACF-S), supports standards-based interfaces, including multi-port 800 Gigabit Ethernet networking and high-radix PCIe Gen5 and CXL 2.0+ interfaces. The company claims that Enfabrica’s ACF-S is the first data center silicon product in the industry to deliver headless memory scaling to any accelerator by incorporating CXK memory bridging to enable a single GPU rack to have direct, low-latency, uncontended access to local DDR5 DRAM at more than 50 times greater capacity than GPU-native High-Bandwidth Memory (HBM). That approach should enable customers to cut their cost of GPU compute by an estimated 50% for large language model (LLM) inferencing and 75% for deep learning recommendation model (DLRM) inferencing, the company claimed.

    Simulation tests suggested ACF-enabled systems could achieve the same target inference performance using only half the number of GPUs and CPU hosts compared to the latest GPU servers.

    The cost of building AI applications today is prohibitive for many organizations, but as processor advances are made, there may come a time when the cost of building and training AI models substantially decreases. Advances in networking processor technologies will, as a result, accelerate the pace at which network operations are integrated into programmable DevOps workflows versus relying on dedicated networking teams to manage top-of-rack switches.

    It’s not clear yet whether cloud service providers will embrace ACF, but the chip makes it clear there is a significant opportunity to reduce the amount of networking infrastructure needed to build and deploy AI applications.

    Less clear, of course, is to what degree machine learning operations (MLOps) might ultimately be folded into DevOps workflows. While developers of AI models create a unique type of software artifact, they still need to be integrated with application code running in a production environment via application programming interfaces (APIs). One way or another, the total cost of building and deploying applications infused with AI models will need to decline.

    In the meantime, the networking bottlenecks that conspire to make deploying distributed computing applications difficult today may soon become overcome as latency issues are increasingly overcome.

  • NETSCOUT Taps F5 to Optimize Custom App Performance

    NETSCOUT Taps F5 to Optimize Custom App Performance

    Through its alliance with F5, NETSCOUT Systems has extended the reach of its nGeniusOne enterprise performance management platform to support custom applications.

    The nGeniusONE platform supports more than 1,000 voice, video and business data applications using NETSCOUT InfiniStreamNG appliances in combination with nGeniusONE to provide visibility into any infrastructure environment, including data centers, private and public cloud and co-location facilities. The integration with F5 extends those capabilities to add support for custom applications via integration with F5 BIG-IP server pool definitions that can now be directly imported into nGeniusOne.

    Eileen Haggerty, area vice president for enterprise product and solutions marketing for NETSCOUT, said that approach enables nGeniusOne to access clear, unencrypted traffic from the BIG-IP Local Traffic Manager.

    As more cloud-native applications built using microservices are deployed across distributed computing environments, network latency is becoming a bigger DevOps challenge. A wide range of networking issues can adversely impact application performance, but without any visibility into network traffic, it can be challenging to determine the root cause of an issue. NETSCOUT has deployed a global network of appliances to surface those issues.

    A recent report published by Cloud Security Alliance (CSA) found the average enterprise uses 464 custom applications and expects to deploy 37 new applications in the next 12 months. At that rate, the number of organizations likely to encounter networking issues is only going to increase, noted Haggerty.

    It’s not clear to what degree network operations (NetOps) teams are becoming integrated with DevOps teams that build and deploy custom applications. The need for both teams to collaborate more effectively is becoming more apparent as more application code is deployed at the network edge. In some cases, developers are now programmatically invoking network resources directly, while other organizations provide developers access to a portal to self-service their requirements within the context of a set of pre-defined guardrails. Regardless of approach, the need for greater visibility into the underlying networks that custom applications depend on has become critical.

    Exactly how much that need will drive organizations to embrace one networking vendor over another remains to be seen. DevOps teams are starting to exercise more influence as organizations realize how much they depend on custom software to drive digital business processes. DevOps teams need to be able to understand whether an issue is the result of a networking problem or an inherent problem with the code written or the way an application has been deployed.

    Of course, DevOps and NetOps teams don’t share a common nomenclature so the cultural divide between these teams can be wide. The simpler it becomes for NetOps teams to share visibility into networking services the easier it becomes to bridge that divide. Developers should be able to see for themselves how changes to application code might potentially improve network performance. In the absence of any proof to the contrary, most DevOps teams will simply assume there is a fundamental flaw in the networking services being provided.

  • Cisco Unveils 800G Networking Platform to Advance DataOps

    Cisco Unveils 800G Networking Platform to Advance DataOps

    At the Open Compute Project (OCP) Global Summit conference, Cisco announced it developed an 800-gigabit switch that consumes significantly less power than the previous generation of its networking equipment.

    Thomas Scheibe, vice president of product management for cloud networking for Cisco’s Nexus and ACI product line, said the throughput provided by the latest 7-nanometer iteration of Cisco One ASIC processors is primarily needed by organizations processing massive amounts of data to train artificial intelligence (AI) models either in a local data center or in the cloud. The challenge is that many of the organizations are looking to build AI models that process massive amounts of data while simultaneously reducing their IT infrastructure’s carbon footprint, he noted.

    Cisco has been able to achieve that goal by continuing to invest in proprietary ASIC processors; they are at the core of its networking portfolio to improve data operations (DataOps), said Scheibe. Many IT teams are also looking to replace legacy network routers and switches that consume more power and reduce energy costs by as much as 77%, added Scheibe. In terms of climate impact, Cisco claimed its 8111-32EH switch can now provide 25.6Tbps at 15% of the power requirement. Cisco projected that switch will save about 10,000 kg CO2e per year compared to a 12.8Tbps switch. That equates to the greenhouse gas emissions generated by an average gasoline-powered passenger vehicle driving 26,155 miles, according to Cisco.

    IT teams also have the option of deploying either Cisco’s network operating system or SONiC—Software for Open Networking in the Cloud—network operating system (NOS).

    Cisco is also providing IT organizations with the option to configure its latest routers and switches to run at either 800, 400 or 100 Gigabits with an eye toward upgrading throughput sometime in the future.

    In general, DataOps as an IT discipline is maturing as organizations realize they need to implement best practices to optimize data flows across their organization. Cisco is giving IT teams the option of employing a standard Ethernet fabric or an alternative fabric that increases throughput by predicting which packets need to be delivered to a specific location based on their attributes and the behavior of previous network traffic. As the volume of data that needs to be accessed by low-latency applications continues to expand, DataOps will become a more critical IT discipline. Historically, storage administrators tended to be responsible for data management, but as these applications continue to proliferate, a new class of DataOps engineers is emerging to optimize the flow of data across distributed computing environments.

    In the longer term, it’s not clear how much carbon dioxide emissions are factoring into IT decisions these days, but there are organizations that have begun to track it as part of an effort to lower their carbon emissions. Most cloud service providers have also committed to being carbon neutral. Cisco is betting achieving that goal will require IT infrastructure upgrades at a time when the amount of data that needs to be processed will only continue to exponentially increase.

  • Distributed Systems: Turning Networking to Your Advantage

    Distributed Systems: Turning Networking to Your Advantage

    Whether it’s the office, the classroom, the store or the bank, a great many spheres of human life have moved online. Each day, we grow more and more used to consuming applications on demand that instantly connect us with the rest of the world. Our expanding appetite for the internet depends on an ongoing trend toward distributed systems, with most companies today spreading their information technology across hybrid and multi-cloud architectures that consist of small, independent and loosely coupled containers. Companies are scaling their applications by deploying more clusters of containers across an ever-broadening surface. There are four key lessons businesses can observe from the proliferation of distributed systems.

    Don’t Underestimate the Benefits of Distributed Systems

    There’s a reason why the trend toward distributed systems persists; they are chock full of benefits.

    Distributed systems are incredibly scalable, as they allow companies to scale applications by adding, replacing or removing nodes as necessary. New applications can be rolled out quickly and in multiple iterations, accelerating time-to-market. Codebases are smaller and easier to change. Distributed systems optimize developer efficiency and team collaboration because numerous teams can work on different parts of a system simultaneously.

    Distributed systems are highly resilient. When (and only when) built effectively, distributed systems will continue working even if a significant part shuts down, as traffic can be rerouted to functioning servers—just look at the resilience of the internet. Fewer single points of failure create more stability and fault tolerance.

    With so many benefits, it’s not difficult to see how distributed systems have enabled our connected, digital economy. Netflix is a prime example of how they have supported the growth of SaaS-based applications. Thanks to a complicated distributed system, anyone on Earth can access a massive library of movies, tv shows, and documentaries to stream whatever they want on demand, paying a monthly subscription.

    While Netflix is considered to be in the entertainment industry, we think of it as a technology company first and foremost because the success of its business model is based on the efficacy of its distributed system. Netflix’s platform is scalable, resilient, performant, efficient and therefore profitable because it is distributed.

    Know That Distributed Systems are Complex and Challenging

    Distributed systems are innately complex and therefore difficult to build and operate. They consist of many asynchronous components that must work in tandem with one another. As the system scales, it becomes even more challenging to understand, let alone operate.

    These challenges are hardly unique to Netflix. Any company that manages a distributed system at scale suffers because of the convoluted nature of distributed systems. Other internet giants like Spotify, YouTube and Twitter also grapple with compounding complexity. If you’re overwhelmed by the labyrinth that is your distributed system, take comfort in knowing that these challenges are (to an extent) unavoidable.

    Turn Networking to Your Advantage

    A distributed system is a set of computers, containers or any other nodes that connect to a network to communicate with other entities by passing messages. What truly allows distributed systems to be ‘distributed’ and to function is the network. This makes the network both a liability and an opportunity. Yes, even the best systems will fail at some point on various levels. There is no such thing as complete control in distributed systems, but that doesn’t mean you can’t turn networking to your advantage.

    Developers can efficiently manage their distributed system by prioritizing networking and employing the right tools across an architecture. Netflix has built exceptionally well-connected systems with servers deployed in thousands of locations worldwide that connect to the control plane in the cloud. If a server fails, traffic can easily be rerouted elsewhere. The distributed system is scalable, resilient, performant and efficient. Robust networking solutions give the team at Netflix visibility into and control over the application.

    Networking truly is the key to bolstering the advantages and overcoming the challenges of distributed systems. Invest resources in your network and it will take care of your distributed system.

    Aim for Simplicity

    Turn networking to your advantage by taking care when building a networking stack. The two most predictable pitfalls to avoid here are not choosing a stack that addresses your unique challenges and differentiators and selecting tools that are overly complicated for your use case.

    It’s all too common for companies building and managing distributed systems to adopt popular or default tools that come with their orchestration platform without giving their suitability much thought. It is never a good idea to copy-paste a networking stack seen elsewhere, assuming that what has worked for others will also work for you. It may, but do not blindly select the stacks everyone is talking about without giving them much thought.

    Many organizations followed the herd by adopting Istio, only to later discover that the service mesh is far too complicated and resource-intensive for their platform. While Istio’s numerous features are helpful for some, they quickly become burdensome. The trending tools are not necessarily the best for your use case.

    Some companies go the opposite route and build their own custom solutions instead of following the herd. Just as Netflix built Zookeeper for service discovery and Spotify built Backstage for API management cataloging, global companies with expansive distributed systems can benefit from the control offered by a custom tool. This option is expensive, time-consuming and not viable for non-tech or smaller companies.

    You’re (probably) not Netflix, so don’t try to be. You may think you have the same problems, but you don’t. Yes, distributed systems are always complex and full of challenges. But the complexity of distributed systems compounds at scale to such an extent that it becomes incomparable. Internet giants like Netflix and Spotify require the advanced features of complicated tools or custom solutions built in-house (and they have the means to invest in these resources). If your platform is a fraction of the size of Netflix’s, your distributed system relies on a far simpler network.

    It’s extremely easy to choose solutions that are overly engineered for your use case, but it’s best to opt for simpler alternatives. Start with simple solutions, gain control of your networking stack and then advance to another level of complexity later on. Gaining control of your network will allow you to tap into the benefits of distributed systems while avoiding some of the challenges. Turn networking to your advantage and make your infrastructure scalable by choosing simplicity over complexity.

  • The Power of Automation and Distributed Sources of Truth

    The Power of Automation and Distributed Sources of Truth

    Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much data–including most network configurations–is still updated manually, often in the middle of the night. To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

    Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

    The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

    The Source of Truth

    More enterprises are embracing network automation because they recognize the efficiencies it can deliver when managing complex networks and the benefits those efficiencies can add to the bottom line. But if you’re going to automate your infrastructure, your automation solution will need to gather authoritative information about it from somewhere. This source of truth holds the knowledge needed to enable automation to make changes to the network.

    Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution. But such a solution doesn’t currently exist. Given the multifarious nature of today’s networks, relying on a single source is both impractical and potentially expensive.

    Rather than asking “What is the single source of truth?” perhaps the better question is “What will provide better data: Creating a single source of truth that tries to synchronize to the entire network? Or accessing distributed sources of truth needed to accomplish the automation in real-time?”

    Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to conduct proper and meaningful automation.

    Cast a Wider Net

    If you’re running a service provider network, for instance, your business is your network. If you’ve spent millions, or even a billion dollars on your network assets, it’s worth your time to have a system in place that accurately manages and maintains those assets. A single source of truth won’t provide that.

    Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

    Finally, the process of trying to create a single source also doesn’t address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

    The case for accessing multiple sources of truth is a relatively simple one: it allows for greater flexibility and enables enterprises to more easily leverage data to benefit their business.

    With the advent of programmable networks–machines talking to machines–the most current automation solutions can access multiple distributed sources of truth–different APIs and databases that are responsible for being the source of truth for different parts of the network – and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

    Automation Hesitation

    So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, there’s concern that not having a single source of truth for network data – or data that may not be 100% accurate – will compromise the automation process. It’s a classic “fear, uncertainty and doubt” thought process: “What if the data is only 70% accurate? If we try to automate with bad data, we’re going to break the network 30%  of the time.”

    Some network teams may believe they can’t automate anything until they can combine their five or six sources of truth into one huge database. At the same time, leadership may be pushing those network teams to move forward with automation to get more value from the network. By choosing to wait until they finally have a “pristine” database, they could lose months or even years of time, to the benefit of no one.

    The solution is to take an incremental approach. Look at all the various network assets–programmable, cloud, legacy, etc.–and start the automation process in the areas where good data exists and where a source of truth doesn’t need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

    Being able to utilize multiple sources of truth is better than worrying about having a “perfect” source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

    Just as important as committing to an automation solution that can integrate with multiple sources of truth to make decisions, is deploying the right automation solution. The most effective automation solution will embrace:

    ● API-first–The only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other.
    ● Data federation and transformation–Having unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language.
    ● Unified view–An abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

    Multiple Sources Equal More Actionable Data

    With today’s modern, programmable networks–and the absolute necessity for enterprises to have access to accurate, real-time network data–relying on a single source of truth is based on a flawed assumption that we can always have a synchronized database, and therefore is not a viable strategy.

    By adopting network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth, mitigating data quality issues and manual errors.

    As an enterprise implements its automation strategy, having multiple sources of truth within the network will result in more accurate, timely and actionable data for automation to succeed, which will increase efficiency and drive the business forward.

  • A Full Pipeline: CI/CD for Network Automation and Orchestration

    A Full Pipeline: CI/CD for Network Automation and Orchestration

    The intersection of CI/CD and network automation has grown substantially over the past few years. Network teams have seemingly reached the point in their automation and orchestration journey where it has become critical to implement a strategy to manage the testing, version control and deployment of both network changes and automation assets. 

    While CI/CD has grown in popularity, there are—at least on the surface—many differences in the types of pipeline implementations to which network teams want to apply the technology: Different tooling, different scenarios and different problems being solved. Despite the seeming disparities, there are some key themes that are consistent throughout most pipeline implementations. For instance:

    Network teams either want to develop pipelines to better manage specific changes to the network or they want to use pipelines to better manage the testing and deployment of automation and orchestration assets like workflows or scripts. Where initially those teams may have turned to network infrastructure-as-code (IaC), a significant (and growing) number are investing in automation asset pipelines. 

    The trust and resources being dedicated to these pipelines is just one of a growing number of indicators that automation and orchestration solutions are maturing and moving beyond initial implementations to large-scale, business-as-usual technologies.

    How Pipelines and Network Automation Complement Each Other

    A close examination of recent pipeline developments provided more clarity about the respective strengths of CI/CD tooling and network automation tools for network change management and life cycle—GitLab, GitHub, Jenkins and CircleCI to name just a few. Most network teams would prefer to stick with a “right tool for the right job” philosophy, wherein the best tool for any given task can easily be integrated into an overall solution. 

    In this context, the “right tool” philosophy looks at pipelines and at network automation/orchestration tools to identify what they do best. Then, a strategy is developed that maximizes the benefit of both technologies. Using this approach, teams can avoid the pitfalls of trying to solve everything with one or the other, leading to a suboptimal process.

    Some good current rules of thumb are based on two simple points:

    • Pipelines focus on creating consistency and repeatability by managing activities related to code versioning, testing coordination, code merging, code validation and approval. The primary benefit of pipelines is the ability to automate the change process.
    • Network automation focuses on generating the network payload and applying that payload to the network elements. This may also include automation of engineering and business logic steps that typically must be performed in a specific order. The best uses of network automation within the change process require attention to business logic, order of operations and network engineering rules.

    By integrating both technologies into a common pipeline, network teams can get the best of both toolsets. 

    The example below illustrates an integrated model where network automation tools provide the engineering logic for the generation, testing and deployment of configuration changes, while the CI/CD tools (represented by the orange arrows) carry the activities through a repeated, automated process, ensuring that the changes go through a consistent path with proper version management, approvals and testing. Multiple teams have successfully implemented this model and they are beginning to iterate their solution to incorporate their unique experiences and improvements.

    The widespread expectation from the industry is that, in addition to the integration of CI/CD and automation into a common pipeline, we will begin to see other indicators of maturation of orchestration and automation. Some of these are areas that are already taking shape, such as the shift in skillsets and competencies outside of traditional CLI-centric engineering toward DevOps and CI/CD skills, or the growing importance of quantifying the business impact of automation and orchestration. 

  • 8 Skills Cloud Architects Need to Succeed

    8 Skills Cloud Architects Need to Succeed

    For cloud architects, a deep understanding of cloud tools and technologies is only the starting point in terms of skills that need to be mastered. Enjoying a successful career as a cloud architect requires much more, including certain skills that are typically not associated with the tech industry. 

    Architecture and Design

    The cloud architect needs to be an expert on end-to-end system design since their primary responsibility is solving a customer’s problems through the use of technology. The architect’s ability to develop a design that solves a business’s problem is where their true value lies. Because design is architecture, the cloud architect must have expert knowledge of all the current and legacy systems that exist in the network and in the data center and also understand how to migrate them to the cloud, matching them to the proper cloud-based systems.

    Network and Data Center Technologies

    Networking and data center skills are critical for the cloud architect because one of their major responsibilities is designing a plan to take the systems that were on the network and hosted in a data center and migrate them to the cloud. To do this successfully, cloud architects must be experts on networking and data center technologies.

    Digging deeper, they must be experts at routers, load balancers, switches, routing protocols, IP addressing and WAN connections whether those are private line-based, VPN-based or software-defined networking. They must be experts on servers and server virtualization and containers and storage, too: Block storage, object storage and file storage. The cloud architect also needs to be an expert at file-sharing protocols such as Server Message Block for Windows and NFS for Linux. Security, too, is an important skill; they must understand how firewalls, IDS/IPS systems and how VPN concentrators work. The cloud architect needs to have full knowledge of databases, understand how web applications work and understand ERP applications and supply chain applications. Good, strong network and data center knowledge is the foundation for architects who are overseeing the migration of tech from the data center to the cloud.

    Business Acumen

     Cloud architects are digital transformation specialists. They must craft end-to-end business solutions for customers with the goal of improving their businesses. If they do not have a thorough understanding of customers’ business, they cannot effectively engineer solutions that will solve their business problems.

    Business skills include the ability to calculate an ROI model based upon the expected value of an opportunity, to read a financial statement and to read a balance sheet. It includes knowledge and understanding of what the CEO, CFO, CIO and CTO care about and being able to communicate with them in ways they understand. Without an understanding of business, cloud architects limit themselves to simply adding or removing technology, which might make business outcomes better or might make them worse.

    Leadership

    Accomplishing anything great requires a team, which means being a great cloud architect requires leadership skills. When working for a client, a cloud architect typically will need to set a baseline of current systems. Accomplishing that effectively might require a team of 50 cloud engineers working together to evaluate the customer’s systems. Leadership skills allow you to effectively manage that team of engineers.

    And leadership skills go beyond effectively managing people as they work on proofs-of-concept and deployments. Leadership skills empower the architect to make sure teams are motivated, are fully engaged with projects and are contributing to success.

    Sales

    When on the job, a cloud architect is constantly selling. The solutions they designed need to be sold to the customer. The plan to implement the solution needs to be sold to management before the necessary resources can be obtained. When it is time to get people to work with us on a project, we need to sell them on its value. Sales skills are employed in a wide variety of ways. Cloud architects sell to customers, internal stakeholders and to management.

    Presentation

    Cloud architects also need exceptional presentation skills because they will be presenting to customers. Those customers could be technology professionals like engineers; they could be presenting to management and/or to C-level executives. Additionally, cloud architects will be presenting information at executive briefings and at conferences. In general, presentations are part of everyday life for the average cloud architect.

    Communication

    Determining the business requirements for any cloud architecture project requires asking a lot of questions. They’re never just handed a piece of paper by a client that says, “Build this.” Without stellar communication skills, it’s difficult—if not impossible—to determine the business’ requirements, meaning the solutions that are designed could be incorrect.

    Even once the business requirements are well understood, the next step is to take those requirements to a team of technology professionals, which means communicating effectively with tech people as well as business people. Communication skills, which include communicating to customers, teammates and various other stakeholders in the organization, are critical.

    Emotional Intelligence

    Emotional intelligence is a critical skill for those who want to increase their professional value and propel their cloud architect career forward. Emotional intelligence increases the capacity for leadership, understanding and communication. When used regularly in the job, it is the best predictor of career success and typically results in about a $30,000 increase in the average person’s salary. For a cloud architect to have a successful career, building on the skills outlined above is critical.

  • Top Nine Skills for SREs to Master

    Top Nine Skills for SREs to Master

    It’s easy to talk at a high level about what site reliability engineers do: They ensure that IT systems achieve availability and performance requirements.

    But which skills, exactly, do SREs need to do to perform their jobs? That’s a more complicated question.

    To answer, let’s look at the top nine site reliability engineer skills that modern SREs (or aspiring SREs) should master. Although SRE skills may vary from one team to the next depending on the types of systems managed and the main types of reliability challenges faced, virtually all SREs need a core set of standard skills that allow them to understand and manage the type of complex, distributed systems they will have to support at the typical organization today.

    Here’s a breakdown of top SRE skills.

    Networking Expertise for SREs

    The network plays a pivotal role in connecting modern, distributed environments. As such, it’s often the culprit when something goes wrong—a lesson that Facebook, for example, learned when a networking problem brought down its entire global infrastructure.

    Situations like this are why SREs should master networking concepts. Even if their organization also employs networking engineers, site reliability engineers need a deep understanding of networking themselves to know when the network is the root cause of an incident and how to resolve network-caused issues effectively.

    Linux and Unix

    If you come from a Windows background but you want to be an SRE, there’s no getting around it: You’ll need to learn how to work with Linux and other Unix-like systems in addition to Windows.

    That’s because, even at organizations that don’t rely heavily on Linux servers, you’re likely to find that Linux and Unix concepts are deeply embedded within other systems that you have to work with. Most public cloud management tools follow the conventions of Linux CLI tools, for example. So do systems like Docker and Kubernetes, even if you run them in a Windows environment.

    Cloud Computing

    Like Linux and networking, cloud computing is another category of skill that modern SREs can’t live without.

    The reason why is almost self-explanatory: Around 90% of businesses use the cloud, and you can’t manage reliability for cloud environments very well if you don’t understand cloud architectures, cloud networking, cloud data storage, cloud observability and so on.

    CI/CD Pipelines

    SREs don’t typically help to develop software, but they nonetheless need a deep understanding of how software is written and deployed—which, at most organizations, today, is a process that happens via a CI/CD pipeline.

    It’s hard to engineer reliability if you don’t know how to address reliability problems that emerge from application source code or deployment processes. Understanding how CI/CD processes work and which tools drive them is key for virtually every SRE today.

    Quality Assurance and Software Testing Automation

    SREs also don’t usually help to test software pre-deployment. That task falls to developers or quality assurance engineers.

    Nonetheless, understanding how software is tested—and how to use test automation to speed tests and expand test coverage—is a vital SRE skill. After all, the more thoroughly and efficiently your team can test software, the greater your chances of catching reliability problems pre-deployment, when they are easier to fix and pose a much lower risk to the business.

    Security Engineering and Response

    Securing is another domain that SREs don’t “own,” but where they nonetheless require significant skills.

    Indeed, good reliability engineering makes security a priority, and vice versa. SREs who don’t understand security fundamentals are at risk of implementing reliability solutions that are effective from a reliability standpoint, but not necessarily secure.

    DevOps

    Although SREs are not DevOps engineers, SRE and DevOps are closely related domains. SREs at most organizations today will be expected to understand DevOps concepts and, in many cases, work alongside DevOps teams.

    So, plan to master DevOps skills as part of your site reliability engineer skills acquisition strategy.

    Incident Management

    Perhaps the single most important type of skill for SREs to learn is incident management. Although many roles may participate in incident response, SREs usually take the lead in organizing the incident response team, communicating with stakeholders and devising the best strategy for resolving each incident as quickly as possible.

    This means SREs should know how incident response roles are structured and understand incident response concepts. They should also be familiar with incident response platforms that automate the complex processes required to ensure rapid, effective incident resolution.

    Managing Postmortems

    In addition to overseeing incident response, SREs may be tasked with managing post mortems. Knowing how to run a postmortem—as well as when a postmortem is necessary, and when it makes sense to use a “blameless” postmortem approach—is an essential SRE skill.

    The list of SRE skills could certainly go on. Above are only the most fundamental types of skills SREs will need for most modern environments. But if you’re just starting out on your journey to becoming an SRE, the nine skill domains described above are a good place to begin acquiring the knowledge you’ll need to excel in an SRE career.

  • IoT Developers: Get Familiar With LoRaWAN for 2022

    IoT Developers: Get Familiar With LoRaWAN for 2022

    IoT Analytics forecast the global number of connected IoT devices would grow to 12.3 billion active endpoints in 2021. That number is expected to grow exponentially in the near future as more and more industries make use of long-range wireless capability. For example, president Biden’s infrastructure plan promised major investment in smart cities and smart municipalities across the United States. 2022 will also see IoT growth in the manufacturing and utility sectors as ‘brownfield industries’ look to update their existing machinery for Industry 4.0. Both of these factors will bring about a massive surge in demand for low power wide area network (LPWAN) solutions using the long range wide area network (LoRaWAN) standard next year.

    LoRaWAN is the standard protocol for LoRa wireless technology. LoRa was built specifically for long range use cases (it’s in the name). This means that technology using LoRaWAN requires significantly fewer repeaters and gateways to cover a large area, like a city, than would be required using traditional technologies. Additionally, LoRa is robust in how it responds to interference, and LoRaWAN sensors use less energy than other sensors, making them more efficient. In fact, ABI Research forecast that, by 2026, LoRa will be the leading non-cellular LPWAN technology.

    In the grand scheme of IoT, LPWAN technology is relatively new. LoRaWAN became an open standard just six years ago when the LoRa Alliance was formed in 2015. This means the main challenge for IoT developers in 2022 and beyond will be educating themselves on the technologies needed to put LoRa-enabled plans into action. There are two big reasons why you should begin that process now: The rising demand for smart cities and Industry 4.0.

    Building Cities Smarter

    When it comes to infrastructure, roads and bridges might come to mind first, but in reality, infrastructure is much more holistic. Utilities like electricity, gas and telecommunications should all be included in any infrastructure discussion. These industries have already come to rely on IoT technologies to collect data and function in the modern world. 

    The government IoT endpoint electronics and communications market is expected to reach $21.3 billion in spending in 2022, according to projections by Gartner. As governments continue to modernize and implement more wireless technology, I expect a good amount of this money to go toward the development of solutions using LoRaWAN to create flexible networks on a very large scale for smart cities. 

    In fact, this movement has already begun. In September, the city of San Jose, California, announced its partnership with a blockchain-based provider to extend the city’s broadband access. In exchange, the city is now hosting and expanding its peer-to-peer IoT network infrastructure.

    Updating Brownfield Industries for Industry 4.0

    2022 will also see IoT advancements in ‘brownfield’ industries. These are industries with legacy, stand-alone machines and processes, such as in the manufacturing and utilities sectors, that weren’t originally created with internet connectivity in mind. Players in brownfield industries already have large install bases of machines that have no way of reporting status or other pertinent data.

    These industries have long been looking at developing IoT solutions to solve this issue. Most are prototyping now with the goal of getting data to flow between large, legacy manufacturing machines with the end goal of improving manufacturing processes. However, unlike other industries where modern updates are often needed to improve efficiency, these manufacturers aren’t going to replace equipment that already gets the job done and has done so for decades. Instead, they need to find an alternate way to gather data and insights from the equipment they already have in place. 

    For many, LoRa-enabled sensors will be the answer. Often, upgrading to new technology requires equipment be substantially changed. That isn’t the case with LoRaWAN solutions, which allow manufacturers to add LoRa-enabled sensors to existing machines. LoRa-enabled sensors are durable, don’t require much maintenance and have low battery footprints. They also allow manufacturers to keep their data on-premises and on their own internal networks, a common preference for these types of industries. These characteristics make LoRa-enabled sensors ideal for manufacturing purposes. 

    In the new year, we will continue to see more pilot deployments go into production to help these industries gather the data they need to improve their processes and, in return, their bottom lines.

    LoRaWAN Resources for Developers

    The intention of the Biden administration’s high-tech infrastructure plans in the United States and the benefits of LPWAN (and LoRaWAN in particular) for private, long-range networks are converging to present a lot of great opportunities for this technology this year. That’s why 2022 will be the year IoT developers need to brush up on their knowledge of LoRaWAN.

    If you are interested in learning more about LoRa, check out the LoRa Alliance or LoRa Developer Portal communities to get started.

  • Kentik Open Sources Five Projects to Advance Network Observability

    Kentik Open Sources Five Projects to Advance Network Observability

    Kentik today unfurled a developer hub, dubbed Kentik Labs, through which it is making five open source projects available as part of an effort to advance observability across network operations (NetOps).

    The five projects are:

    kTranslate: A system for pulling and pushing network data that is the basis of the Kentik Firehose integration the company created for the New Relic observability platform

    NetDiag: Scalable, asynchronous implementations of low-level network diagnostics

    Convis: Example code showing how to attribute process and container information to network traffic via the Linux kernel using eBPF

    kProbe: A high-performance host and sensor network probe (PCAP)

    Grafana App: A real-time tool for ingesting and querying network data

    Nick Stinemates, vice president of business development at Kentik and co-chair of Kentik Labs, said the goal is to enable DevOps teams to incorporate NetOps within the workflows already being employed to programmatically manage the rest of IT.

    Stinemates noted that, as IT environments become more distributed, managing NetOps has become more challenging. If there is a failure, it can be difficult for DevOps teams to determine if the issue is due to application code, the underlying infrastructure or some other root cause. Kentik Labs is committed to providing tools that will help DevOps teams reduce their mean time to recovery (MTTR), he added.

    Most NetOps teams increasingly rely on software to manage distributed networks either in the form of graphical tools provided by router and switch vendors or by using the Python programming language and the open source Ansible automation framework that enables IT teams to declaratively manage IT infrastructure.

    As the teams that manage network operations gain more proficiency with those tools, it becomes simpler to incorporate them within the construct of a larger DevOps team. While DevOps teams have been programmatically managing IT infrastructure-as-code (IaC) for years, network management has largely remained in a separate silo. However, as more applications are deployed in the cloud, it’s clear NetOps needs to become more integrated with the rest of the workflows employed to deploy and manage a highly distributed IT environment, said Stinemates.

    Less clear is to what degree the networks that make up a hybrid cloud computing environment will continue to be managed by network administrators versus site reliability engineers (SREs) that are starting to assume responsibility for managing compute and storage.

    Regardless of who manages the network, the next generation of microservices-based applications that are dependent on application programming interfaces (APIs) to call various services are much more latency-sensitive than previous generations of applications. Many of those applications will regularly experience performance issues due to networking issues that are often not readily apparent to DevOps teams. The goal should be to, at the very least, arm those DevOps teams with the tools required to confirm the source of those issues before a “war room” is convened to determine how to address the issue.