A Letter to the DevCentral Community
Hey there DevCentral community, I’m Tony Hynes, Director of Community Development for F5. Given the scale of change to the look and functionality of DevCentral, and the passionate responses we’ve received as a result of the change, I wanted to take some of your time to address a few things. But if you’re in a hurry here’s the tl;dr version: We know this relaunch didn’t go exactly as planned and we’re committed to fixing it. First off, I want to apologize for forklifting your experience without enough prior communication. We should have given the community a better heads up on what exactly was going to change.We’re asking the DevCentral user to change a lot of known behaviors (login, contribution maintenance, account management) and we didn’t do a good job hitting that message early and often. Total failure on our part. Second, we are working through the challenge of locating the content you need both on-site and through search engines. We are actively working on a few fixes that will alleviate some of the pain, and we will be adding “help” functionality which will act as a guide to help you work with the new DevCentral search, filter, and navigation options. We should have had this complete at launch. Again, mea culpa. Third, change is hard. The old platform was just that—old. There was no path forward on the old platform to build the type of experience we know the community wanted or to build the features the community needs. The community deserved a better site and we weren’t going to be able to build that on-top of the old one. In the short term, that means we have to make some compromises and take a few steps back in order to move forward. Which leads me to address what’s coming. A long-standing request from the community has been to consolidate credentials across F5 properties. DevCentral will be the first F5 property to on-board the necessary technology, and soon you’ll be able to use this SSO on other F5 sites. Also, from the “big ask” bucket is the ability to respond to Q&A via email. The new platform supports not only Q&A, but also article and message comments as well. This adds a whole new level of engagement capabilities to the site, and validates the message that DevCentral belongs to the community, and we want to hear your voice. Fourth, the members of my team are as much members of DevCentral as they are owners, and they are equally passionate. They want the improvements to come just as fast and furious as you do. They’re not satisfied with the relaunch either and are as committed to making this right as I am. Finally, please know that we understand the pain caused as a result of the changes and the impact to your daily workflow. We are actively working to resolveevery issue with complete urgency. Thank you for sticking with us through this transition and for understanding that our goal is a better experience for all. You have, once again, proven that this is a community that cares enough to provide feedback (good and bad). For that, I cannot thank you enough! Tony HynesDeploy Consistent Application Services with BIG-IQ and AS3
BIG-IQ 7 is out now and improving on the integration with our Application Services 3 Extension (AS3) released in BIG-IQ 6.1. In the below video, Aaron Johnson walks you through deploying application services in two datacenters, managing them all within BIG-IQ. If you're not familiar with AS3, it's F5's lightweight Javascript iControlLX plug-in offeringdeclarativeinterfaces for application management. Read more on AS3 at Clouddocs.f5.com. For BIG-IQ 7.0 and above, F5's AS3 template library referenced in the video is available at DevCentral's GitHub Organization .2020 State of Application Services Survey
Since 2015, F5 has been surveying the tech industry to learn about key issues surrounding application deployment and delivery. Initially called the State of Application Delivery, affectionately ‘SOAD,’ last year we renamed the reportto The State of Application Services. This new name highlights the critical role that application services of all varieties play in the security, availability, and performance of the applications at the very foundation of the digital economy. Once again, for 2020, we would love to understand your company’s current application architectures to help shape F5 application services strategy. We are exploring the following questions: Why application architectures are changing in your environment? What are your current operational opportunities and challenges? How the role of application services is evolving in the age of the “SuperApp”/Digital Transformation? How important are automation and application analytics to your application deployments? What is your confidence to withstand an application security attack? As reference, here is an excerpt from the 2019 Survey: When we looked at confidence by roles: Cloud/cloud-architects were the most confident in public cloud security. Network roles were most confident in on-premise workloads. Security folks were the second most confident in public cloud and third most confident for on-remises!! That is the deep insight you get from this report and we hope you will participate. This survey is being administered by an independent research company on behalf of F5. Your answers will be kept strictly confidential and your feedback will be combined with feedback from all respondents worldwide. As a thank you for participating, you will receive a copy of the final, aggregated survey results. If you are interested in taking the survey, please continue to this link.We will be taking responses until October 10, 2019.
F5 Synthesis: What Makes a Services Fabric?
#SDN #SDAS What makes a services fabric, well, a fabric? Earlier in 2013 when discussing the evolution of application delivery and F5 I posed a question to which, at the time, didn't have an answer. It was simply "What's Next?" As the time has gone by, the answer to that has become clear. What's next is an evolutionary step in the history of F5 and, more broadly, application delivery. What's next is the evolution from application delivery networks to services fabric. The ballooning volume of connections, data, users, devices and applications has a very real impact on the data center. It forces changes in both the application and the network architecture to enable businesses to act and react rapidly, despite the need to coordinate across an increasingly complex web of devices, networks and applications. To enable businesses today means enabling IT, and to do that requires an evolution of the entire data center toward a more flexible, dynamic and ultimately service-focused approach to provisioning and management. That means application delivery architectures must also evolve beyond traditional models. Application delivery networks must evolve into services fabric that support a more integrated, collaborative approach to managing what is increasingly a software-defined and application-driven world. So what makes a services fabric a "fabric"? The industry accepted definition of "fabric" generally refers to a topology in which a set of hardware and/or software network elements are connected with each other and offer a consistent set of services. Fabric implies a means of distributing network functions across the elements, often in real-time. The definition of a services fabric is not all that different. At the heart of F5 Synthesis is a High Performance Services Fabric: a topology in which a set of application service elements (F5 platforms deployed on any combination of hardware and software) are connected with each other (Device Service Clustering) and offer a consistent set of services ( mobility, cloud, platform, DNS, access and security). ScaleN enables the distribution of service functions across the F5 services fabric to achieve the economy of scale and performance expected of fabric-based technology. This is not just redundant pairs (or multiple sets) of devices clustered together so that traditional aggregation protocols can be used to distribute traffic across them. While such technologies can certainly be used to emulate a fabric-like model, the result is neither as robust nor reliable as a true services fabric. What's key to being considered a services fabric is twofold: it must be all active and service-focused. All-active. All elements must be actively participating in the fabric.This is necessary to realize the real-time reliability of services expected. If a problem arises with a service on one element, the fabric must be able to move that service - in real time - to another element. To achieve that, all elements must be active and able to take on new services. Similarly, if a service must be scaled to meet surging demand, it must be possible to provision another service instance elsewhere in the fabric. Thus, an all-active model is a requirement. Service-focused. The purpose of a network fabric is to deliver network services. The purpose of a service fabric is to deliver services, specifically for application delivery, application services. Applications experiencing a surge in demand require not only that application resources be scaled to meet that demand, but its associated application services as well. A services fabric must be able to scale an application's services in tandem with demand. Conversely, problems affecting one service should not affect another. When issues arise in a network fabric, a new path is found to mitigate the problem. When issues arise in a services fabric, a new chain (path) needs to be found to avoid disruption. Thus, a services fabric must be focused on service-level availability, not just device-level availability. There's nothing all that special about clustering ADCs together into a mesh of devices. Plenty of folks can do that. What's special about the F5 High Performance Services Fabric is that it moves beyond a focus on managing ADCs and marrying pairs of ADCs to applications and focuses on application services. It creates a fabric, a pool of services resources, atop which application services can be provisioned, managed, migrated, and extended. Service mobility is imperative to enabling a variety of emerging architectures and deployment models. When applications are bound to a specific ADC instance rooted to a topology, it inhibits the ability to move that application or even extend it into the cloud. F5 High Performance Service Fabric, in conjunction with F5 Synthesis' Intelligent Services Orchestration model eliminate such constraints, and ensure that the fabric is not a constraining factor. Rather, it is an enabler of more fluid, mobile architectures and models. The future of application delivery is a services fabric based architecture. Additional Resources: F5 Synthesis: The Time is Right F5 and Cisco: Application-Centric from Top to Bottom and End to End F5 Synthesis: Software Defined Application Services F5 Synthesis: Integration and Interoperability F5 Synthesis: High-Performance Services Fabric F5 Synthesis: Leave no application behind F5 Synthesis: The Real Value of Consolidation RevealedF5 Synthesis: High-Performance Services Fabric
#SDN #Devops #Cloud #SDAS #SDDC To achieve the economy of scale necessary to ensure no application is deprived of critical application services, you need to abstract resources. In the early days of cloud computing we talked a lot about how the economy of scale offered by cloud was achieved mainly through abstraction of resources. Compute, network and storage resources were abstracted and pooled together such that they could be provisioned as services on-demand. That economy of scale ensured that the cost of using those services decreased, making them affordable for even the smallest of organizations. In the data center, however, similar economy of scale has been difficult to achieve because the abstraction at the network layers has remained elusive. SDN has recently emerged as a front-runner in the data center as a provider of that abstraction, turning disparate network elements into a cohesive fabric of network resources, dynamically adjusted to deliver the best performance and availability to any application that might be delivered over its formerly rigid pipes. But SDN doesn't provide an easy answer for layer 4-7 (application) services. Application services must be able to match the economy of scale offered by server virtualization and SDN / NFV if economy of scale in the manner of cloud computing is to be realized. That's why F5 Synthesis contains as a key component a high-performance services fabric. And I do mean high performance. Its aggregate connection capacity is 9.2B - more than one connection for every person on the planet or 3 times the capacity needed to connect every Internet user across the globe*. It can support up to 80 virtual instances per device and has an aggregate throughput of 20TB. All-active clustering thanks to ScaleN with a focus on application services ensures fault and resource isolation, so neighboring tenants can't starve your services. The services fabric provides application- and service-level control and failover to deliver industry-leading reliability. Workloads can be moved across the fabric without interrupting other services and can be scaled to meet the business demand. F5's high-performance services fabric supports traditional and emerging underlay networks. It can deployed a top traditional IP and VLAN-based networks, works with SDN overlay networks using NVGRE or VXLAN (as well as a variety of less well-known overlay protocols) and integrates with SDN network fabrics such as those from Cisco / Insieme, Arista and BigSwitch among others. The services fabric model enables consolidation of services onto a common platform that can be deployed on hardware, software or in the cloud, reducing operational overhead by standardizing management as well as deployment processes to support continuous delivery efforts. By sharing service resources and leveraging fine-grained multi-tenancy, the cost of individual services is dramatically reduced, enabling all applications regardless of size to take advantage of services that are beneficial to their security, reliability and performance. Additional Resources: F5 Synthesis: The Time is Right F5 and Cisco: Application-Centric from Top to Bottom and End to End F5 Synthesis: Software Defined Application Services F5 Synthesis: Integration and Interoperability [*] Based on Sept 2013 Internet user population of 2.4B http://www.internetworldstats.com/stats.htmLoad Aware Fabrics
#cloud Heterogeneous infrastructure fabrics are appealing but watch out for the gotchas One of the "rules" of application delivery (and infrastructure in general) has been that when scaling out such technologies, all components must be equal. That started with basic redundancy (deploying two of everything to avoid a single point of failure in the data path) and has remained true until recently. Today, fabrics can be comprised of heterogeneous components. Beefy, physical hardware can be easily paired with virtualized or cloud-hosted components. This is good news for organizations seeking the means to periodically scale out infrastructure without oversubscribing the rest of the year, leaving resources idle. Except when it's not so good, when something goes wrong and there's suddenly not enough capacity to handle the load because of the disparity in component capacity. We (as in the industry) used to never, ever, ever suggest running active-active infrastructure components when load on each component was greater than 50%. The math easily shows why: It's important to note that this scenario isn't just a disaster (failure) based scenario. This is true for maintenance, upgrades, etc... as well. This is why emerging fabric-based models should be active-active-N. That "N" is critically important as a source of resources designed to ensure that the "all not so good" scenario is covered. This fundamental axiom of architecting reliable anything - always match capacity with demand - is the basis for understanding the importance of load-aware failover and distribution in fabric-based architectures. In most HA (high availability) scenarios the network architect carefully determines the order of precedence and failover. These are pre-determined, there's a primary and a secondary (and a tertiary, and so on). That's it. It doesn't matter if the secondary is already near or at capacity, or that it's a virtualized element with limited capacity instead of a more capable piece of hardware. It is what it is. And that "is" could be disastrous to availability. If that "secondary" isn't able to handle the load, users are going to be very angry because either responsiveness will plummet to the point the app might as well be unavailable or it will be completely unavailable. In either case, it's not meeting whatever SLA has been brokered between IT and the business owner of that application. That's why it's vitally important as we move toward fabric-based architectures that failover and redundancy get more intelligent. That the algorithms used to distribute traffic across the fabric get very, very intelligent. Both must become load aware and able to dynamically determine what to do in the event of a failure. The fabric itself ought to be aware of not just how much capacity each individual component can handle but how much it currently is handling, so that if a failure occurs or performance is degrading it can determine dynamically which component (or components, if need be) can take over more load. In the future, that intelligence might also enable the fabric to spin up more resources if it recognizes there's just not enough. As we continue to architect "smarter" networks, we need to re-evaluate existing technology and figure out how it needs to evolve, too, to fit into the new, more dynamic and efficiency-driven world. It's probably true that failover technologies and load balancing algorithms aren't particularly exciting to most people, but they're a necessary and critical function of networks and infrastructure designed to ensure high-availability in the event of (what many would call inevitable) failure. So as network and application service technologies evolve and transform, we've got to be considering how to adapt foundational technologies like failover models to ensure we don't lose the stability necessary to continue evolving the network.
