One of the biggest unknowns when launching a new service or application is understanding how many users will use it and how much strain it will put on the application. Will it take off quickly and attract hundreds of thousands of users and significant traffic? Will there be a slow but steady climb? Or will traffic have peaks and valleys based on time of day, day of week, internal events, or industry or world events? Many businesses today are tackling these questions through Auto Scaling.
The Amazon Web Services (AWS) Auto-Scaling group service (ASG) is a very good [first] example of this capability. This service gives businesses elasticity in their server use based on predetermined usage criteria. Compute resources can be scaled up and down:
- Dynamically, based on conditions specified by the user (i.e., increasing CPU utilization as certain traffic conditions are reached).
- Predictably, according to a schedule defined by the user (i.e., every Friday at 8 a.m. EST from Nov. 1 – Dec. 24).
Even the most casual customers today expect and demand relatively quick load times. Therefore, whenever a network is bottlenecked and latency issues rear their ugly head, frustration quickly follows. But when that latency appears in your network and affects your mission critical business operations, the frustration can become much more severe, as latency can have a significant effect on your bottom line.
I am very excited to announce the release of CloudWeaver Analytics, a major product that rounds out the CloudWeaver platform. The new product, based on Network Science and Machine Learning technologies, complements Discovery and FlowMapper, delivering a fundamental piece of our Application Defined Networking vision.
With CloudWeaver Analytics , Amazon Web Services (AWS) users get real-time actionable data about the activity and health of cloud infrastructure with a radically simplified approach. This comprehensive knowledge, coupled with real-time analysis, helps users identify and quickly remedy any bottlenecks or scalability issues that may occur. Specifically, CloudWeaver Analytics enables you to understand live connections and behaviors to avoid downtime and improve performance. The product also provides the following benefits:
Analyze your infrastructure data and scale faster. By discovering the inherent organization of your application in groups and flows, you’re able to ensure that the load is well-balanced in each group, helping you scale consistently and secure your application quickly.
In order to make sure your applications are up and running, as they should in the cloud, engineers need to rely on alarms that alert them when something out of the ordinary occurs. Because DevOps engineers can’t simply drop what they’re doing and tackle the potential problem every time an individual alarm sounds, sometimes these engineers aren’t able to investigate such an alarm until several minutes to several hours after it goes off. But because successful IT operations and management is so vital to your business, it’s important to get these problems remedied as quickly as possible.
When engineers finally have the time to look at an alarm, they generally have to reconstruct what the application looked like at the time it sounded in order to recreate the right environment in which to troubleshoot and see what went wrong. Because alarms go off throughout the day, it can be hard to pinpoint the precise configuration of infrastructure when trying to troubleshoot. Engineers have to determine which components were communicating with one another at that given point in time, how much latency was experienced, and the other components that caused the alarm to go off. Due to the technical nature of these reconstructions, the process of creating them is time consuming and prone to errors.
Last week, I talked about a concept that is intrinsically tied to what we are doing here at Lyatiss: TCP ex-Machina. Today, I want to dive a bit further into the unique benefits afforded by the “ex-Machina” innovation and how it ties in so nicely with the new CloudWeaver capabilities.
Capable of generating algorithms for both networks in which parameters are known and for networks where prior knowledge is undetermined, the simulated version of TCP ex-Machina outperforms largely existing TCP variants.
There is no question that SIGCOMM, the ACM’s flagship annual conference on the applications, technologies, architectures, and protocols for computer communication, is one of the most respected conferences in the network research space.
This year, one of my favorite authors, Pr. Hari Balakrishnan—professor of Computer Science at the Massachusetts Institute of Technology (MIT)—signed a wonderful paper TCP ex-Machina
The work presented in August, while both Google and AWS were experiencing big outages related to some network issues, has to be put in perspective with the other research professor Balakrishnan did in the past. In particular, this work echoes previous publications he did in 2001: the Congestion Manager (CM) as well as RON (Reliable Overlay Network). Congestion Manager and RON are both solutions following the end-to-end principles I mentioned in a previous blog.
In my previous blog, I mentioned the need for common abstractions and APIs to decouple application run-time environment from the Cloud service provider for high portability.
This resonates with the great debate as to whether OpenStack should build and maintain its own set of differentiated APIs or leverage the Amazon Web Services (AWS) API. I remarked that OpenStack Board of Director leader Randy Bias is taking an active stance: He contends that creating its own API will harm the OpenStack community. Moreover, doing so will completely repudiate the original mission of OpenStack—to produce a ubiquitous open source cloud computing platform for both public and private clouds.
“I’ve made no secret of my belief that this choice will harm OpenStack, and perhaps already has,” Bias wrote in a letter to the OpenStack community. “Now, the issue has become urgent, and I hope to convince you to join me in advocating that OpenStack immediately and deliberately embrace the APIs and features of established public clouds.”
The cloud market is certainly standing firmly on its two feet, with recent research indicating that the market on a whole will balloon to $20 billion by the end of 2016. That’s because decision makers are repeatedly asking themselves why they should undertake hefty capital expenditures in infrastructure when that infrastructure could instead by leased from a cloud provider, with businesses only responsible for paying for what they use.
According to the research, Infrastructure as a Service (IaaS) accounted for more than half of the revenue from the public cloud in 2012, and it’s expected to have a compound annual growth rate (CAGR) of 37 percent through 2016. Meanwhile, Platform as a Service (PaaS) accounted for 24 percent of the revenue, and it’s expected to have a CAGR of 41 percent through 2016. The infrastructure SaaS sector, which does not include enterprise SaaS revenue, represented 25 percent of total cloud revenue in 2012 and is expected to generate a 29 percent CAGR through 2016. While 69 percent of survey respondents indicated cloud spending will increase in both 2013 and 2014, 83 percent said they’re facing “significant roadblocks to deploying their cloud computing initiatives” according to research conducted by TheInfoPro.
After receiving lots of hype, the VMware NSX network virtualization platform was officially unveiled during VMworld, held during the last week of August in San Francisco. The platform makes NSX compatible with a majority of networking hardware and represents the implementation of the company’s vision of a software-defined data center.
The unveiling of the platform—which includes the ability to control infrastructure hardware providers and virtualize network functions like firewalling—certainly represents a great marketing strategy. The NSX platform for network virtualization aims to enable businesses to be more agile, deploying applications with greater speed, efficiency and security. The platform boasts switching, bridging, routing and firewall capabilities that are built into the hypervisor; as a result, network administrators are granted unprecedented control, the company says.
The statistics might say otherwise—with Amazon Web Services (AWS) expected to emerge as a $3.8 billion titan by the end of 2013 and to experience a 71 percent growth in the amount of websites it hosts—but AWS is finding itself in some hot water.
Despite the company being touted by many for offering a complete set of infrastructure and application services that allow companies to run virtually everything in the cloud, many users are starting to see beyond the bells and whistles and hone in on the service’s limitations.
According to panelists who convened at the end of August to discuss AWS, the top challenges plaguing the platform center around networking and security, as well as Amazon’s Virtual Private Clouds (VPC) and Elastic Block Store (EBS). The panelists, all of whom have at least 1,000 instances running on the platform, lambasted AWS for its user complexities and remaining mum on how the system works, with one panelist going so far as to say, “Amazon has a culture of secrecy.”
In the context of today’s Social, Mobile, the Cloud and Big Data era (also recognized as the Nexus revolutionizing business and society), the question is if we can continue with the same network principles given our increasing dependence on shared Internet/Cloud infrastructures. The complexity and unpredictability are increasing daily, and not all applications can cope with huge uncertainty and complexity. This situation also has an enormous cost in terms of Opex (as a function of complexity) and Capex (as a function of overprovisioning to deal with unpredictability). This explains why SDN was invented…and why it is becoming so popular.
Recently, I was a panelist at GigaOm Structure. The group gathered to discuss a huge topic — Application Aware Networks, which are tightly connected to Software Defined Networking and Application Defined Networking (ADN), although they are not exactly the same concepts.
Personally, I define Application Aware Networks as communication networks that take care of the Apps they support, while Application Defined Networking denotes the activity of dynamically adapting the interconnection of resources of an application infrastructure. Thus, an ADN solution can rely on Application Aware Networks to adapt the resource interconnections of an application, while also leveraging other capabilities like upgrading or reconfiguring the related resources.
In my last post, I described how Flow Intelligence can quickly remediate cloud bottlenecks and oversizing. In this post, I reveal a cutting-edge technology that offers the most efficient way to get the real-time data required to build Flow Intelligence. It is based on network sensors that can be deployed in any virtual equipment of a Cloud infrastructure to jointly collect data from the transport layer (L4) and the local system.
Lyatiss is first to deliver this revolutionary technology. The principle is to leverage and amplify the knowledge and the work of the transport layer and its congestion protocol, which has enabled the unlimited expansion of the Internet for the last 25 years. L4 amplification is a critical building block of any Application Defined Networking solution.
Do you remember Newton’s first law? An object in motion remains in motion—and at a constant velocity… Essentially, momentum is directly related velocity. Feel the cloud momentum build this week, kick-started by Velocity 2013.
Lyatiss is a growing force in cloud innovation, and we are excited to showcase our CloudWeaver® platform at Velocity 2013, June 18 – 20 in Santa Clara, and at Structure 2013, June 19 – 20 in San Francisco.
In January, I introduced the concept of Flow Intelligence as a building block of Application Defined Networking (ADN). And what I mean by the concept is essentially flow-based infrastructure intelligence.
With Application Defined Networking, applications can control and adapt their networking environment to optimize their own delivery and performance across public and private cloud networks without sacrificing portability or security.
As the first building block of ADN, Flow Intelligence is the ability of a network of resources to collect and analyze end-to-end monitoring data. Flow Intelligence captures the communication patterns and issues of an application and detects anomalies such as bottlenecks or oversizing. With that information, users or applications can make real-time decisions to remediate the problems. Flow Intelligence enables the cloud system to reach or return to fluid and efficient performance quickly in a very dynamic and ever-changing environment.
As the popularity of public clouds gains momentum, the battle is heating up among cloud IaaS (infrastructure as Service) providers. As a multi-billion-dollar IaaS cloud provider, Amazon Web Services (AWS) is leading the battle. But Google, Microsoft, Rackspace, IBM, and Hewlett-Packard are very active too. Last week Google announced that Google Compute Engine is now available to everyone. Google revealed unique features like advanced routing to help create gateways and VPN servers.
Clearly Google is serious about the networking aspect of public clouds. And we expect all cloud providers will be in the near future. Indeed, now everybody leveraging IaaS is aware that making the most out of your public cloud resources can present some hurdles, specifically because of various latency and network congestion issues. At the AWS partner summit a few weeks ago in San Francisco, Matt Wood, Principal Data Scientist at AWS, presented a very clear statement of the performance problem, spanning architecture design to operational aspects: Latency the Worst NightMare.
As a child I was fascinated by clouds (and stars). I remember looking out the back of my parents’ car and following clouds dancing in the sky. The clouds were telling me stories like a picture book and developing my imagination.
Now, as the CEO of a startup, I am still inspired by clouds. As you know, one founds a startup to change the world for the better. Cloud-computing is changing our IT world. We are all inventing clouds and creating the future. The mission of our company is to ensure that no barrier will ever slow you down. This is why Lyatiss is automating cloud-computing performance.
The 2013 Open Networking Summit (April 15 to 17) showcased the immense innovation that has taken place in the networking industry in the past year. Startups and incumbents alike have developed significant offerings in SDN controllers, network virtualization, network function virtualization, software appliances, and the like.
Among the announcements and demonstrations were: the OpenDaylight project, Intel’s Open Network Platform, Cisco’s Open Network Environment, and many others. Together with these there were also significant end user initiatives and proofs of concept including Goldman Sachs’ in-house initiatives.
However, a couple of things struck me after 3 days of sessions:
- We were no closer to having a universally agreed to definition of SDN
- There was a big blur on the overlaps and differences between SDN, Network Function Virtualization, and Network Virtualization
2013 starts full speed!
The Networking revolution is really here! Take a look at this SDN Central post to know more.
But the most exciting date for us is today: January 28th, we are launching Lyatiss and introducing CloudWeaver!
Pioneering application defined networking, today, we announce the public beta version of CloudWeaver for AWS. Any user of Amazon Web Service can test CloudWeaver, generate its cloud network map in just minutes and check the flow intelligence at a glance! That’s cloud operations at your fingertip.
CloudWeaver is the first application defined networking solution. It is accessible to any cloud user TODAY!
Do you know why Van Jacobson invented the famous Additive Increase, Multiplicative Decrease (AIMD) algorithm in 1988? It was the result of an unexpected Internet collapse. Initially, the Internet had been designed without any congestion control. In fact, the Internet was not supposed to become so popular! Nobody was worrying on congestion before 1984 (RFC 896). But then a congestion collapse happened in 1986 when the NSFnet phase-I backbone dropped three orders of magnitude from its capacity of 32 kbit/s to 40 bit/s.