Infrastructure as code can certainly be considered a key component of the IT revolution in the last 10 years (read "cloud") and more recently the DevOps movement. It has been widely used in by the developer community to programmatically deploy workload infrastructure in the cloud. Indeed the power of describing your infrastructure as a definition text file in a format understood by an underlying engine is very compelling. This brings all the power of familiar code versioning reviewing and editing to the infrastructure modeling and deployment, ease of automation and the promise of elegant and simple handling of previously complex IT problems such as elasticity.
Here's an Ansible playbook, that a 1st grader could read and understand (or should):
The idea of using a simple human like language to describe what is essentially a list of related component is nothing new. However the rise of the DevOps movement that puts developers in control of the application infrastructure has clearly contributed to a flurry of alternatives that can be quite intimidating to the newbies. Hence the rise of the "SRE", the next-gen Ops guru who is a mix between developer and operations (and humanoid).
Continuous Configuration management and Automation tools (also called "CCA" - one more 3 letter acronym to remember) come in a variety of shapes and forms. In no particular order, one can use Puppet manifests, Chef recipies, Ansible playbooks, Saltstack, CFEngine, Amazon CloudFormation, Hashicorp Terraform, Openstack Heat, Mesosphere DCOS, Docker Compose, Google Kubernetes and many more. CCAs can be mostly split between two categories: runtime configuration vs. immutable infrastructure.
In his excellent TheNewStack article, Kevin Fishner describes the differences between these two approaches.
The key difference between immutable infrastructure and configuration management paradigms is at what point configuration occurs.
Essentially, Puppet style tools apply the configuration (build) after the VM is deployed (at run time) and container style approaches apply the configuration (build) ahead of deployment, contained in the image itself. There is much debate in the devOps circles about comparing the merits of each method, and it's certainly no small feat to decide which CCA framework (or frameworks) is best for your organization or project.
Once you get past the hurdle of deciding on a specific framework and understanding its taxonomy, the next step is to adjust it to make it work in your unique environment. That's when frustrations can happen since some frameworks are not as opinionated as others or bugs may linger around. For instance, the usage of the tool will be loosely defined, leaving you with a lot of work ahead to make it work in your "real" world scenario that contains elements other than the typical simple server provided in the example. Let's say that your framework of choice works best with Linux servers and you have to deploy Windows or even worse you have to deploy something that is unique to your company. As the complexity of your application increases, the corresponding implementation as code increases exponentially, especially if you have to deal with networking, or worse persistent data storage. That's when things start getting really "interesting".
Assuming you are successful in that last step, you still have to keep up with the state of the infrastructure once deployed. State? That stuff is usually delegated to some external operational framework, team or process. In the case of large enterprises DevOps initiatives are typically introduced in smaller groups, often from a bottom up driven approach of tool selection, starting with a single developer preference for such and such open source framework. As organizations mature and propagate these best practices across other teams, they will start deploying and deleting infrastructure components dynamically with high frequency of change. Very soon after, the overall system will evolve to a combination of a large number of loosely controlled blueprint definitions and their corresponding state of deployment. Overtime this will grow into an unsustainable jigsaw with occurrence of bugs and instability that will be virtually impossible to troubleshoot.
One of the approaches that companies such as Quali have taken to bring some order to this undesirable outcome is adding a management and control layer that significantly improves the productivity of organizations facing these challenges. The idea is to delegate the consumption of CCA and infrastructure to a higher entity that provides a SaaS based central point of access and a catalog of all the application blueprints and their active states. Another benefit is that you are no longer stuck with one framework that down the road may not fully meet the needs of your entire organization. For instance if it does not support a specific type of infrastructure or worse becomes obsolete. By the way, the same story goes for being locked to a specific public cloud provider. The management and control layer approach also provides you a way to handle network automation and data storage in a more simplified way. Finally, using a management layer allows tying your deployed infrastructure assets to actual usage and consumption, which is key to keeping control of cost and capacity.
There is no denying the agility that CCA tools bring to the table (with an interesting twist when it all moves serverless). That said, it is still going to take quite a bit of time and manpower to configure and scale these solutions in a traditional application portfolio that will contain a mix of legacy and greenfield architecture. You'll have to contend with domain experts in each tool and the never ending competition for a scarce and expensive pool of talent. While this is to be expected of any technology, this is certainly not a core competency for most enterprise companies (unless you are Google, Netflix or Facebook). A better approach for more traditional enterprises that want to pursue this kind of application modernization is to rely on a higher level management and control layer to do the heavy lifting for them.
An Early Access customer was asking me the other day about the origin of the CloudShell OVA I generated for him. I just mentioned this was using our own internal platform also running CloudShell as an internal delivery service. We have the capabilities to generate the latest image of our software using CloudShell pulling in from our code repository. This image can then be shared with other customers for new feature testing or our own internal development team. When I recalled that story with the customer he expressed interest to do just that type of workflow in their own environment, no questions asked. "That's just what I need for my folks" he replied.
This in turns opened up a few fundamental observations inside my highly caffeinated brain:
An ever present challenge for product managers and alike is to figure out what our target market needs, without wandering around in various directions for too long. Sometimes you stumble across a nugget that's the key validation point that you were after, but most of the time you end up listening to the laud voice that seems to gather most of the attention and may guide to a backward point in your journey or even worse, a "cul de sac". Quite often the best conversations with the "community" of potential adopters are in the early stages, when they share their frustration with a problem, before they may have an agenda with a specific feature or workflow in your product. These interactions tend to happen with good odds on the tradeshow floor, such as the last Cisco Live event in Vegas (no pun intended) . Since chance encounters take a lot of time and volume to really happen, let's consider other alternatives.
The topic of trying things out internally is a common theme in software companies but too often overlooked. Powerful technology trends such as Docker were started that way. In some way it is best illustrated with Apple's approach, who considers their first adopters will be internal employees.
We tend to spend all our energy building a great product for our potential customers and yet we underestimate how it could benefit ourselves in the first place. In the case of Quali, this was all about reducing the time our ever too slim QA team spends validating the various configurations was a slam dunk. What could be easier than procuring them with ready to go images of our latest version? Yet it took some internal commitment and resources to make it happen. It is now a great vector of feedback and efficiency that provides a powerful story when presented to external users. Until that happened it would have been hard to extract that information from our customer.
To sum up, there are different avenues to figure out what your customers want. The pull model is about discovering what the market needs, or may want, relying on the willingness or to share their challenges or even ability to express them. The DIY model is all about experimenting internally and sharing this experience with your potential market. Both are valid approaches we at Quali have been actively using at different maturity level of our product journey. Now it's finally time for that well deserved espresso.
The summer of 2016 has been a hectic one for Quali, with our new website coming up, multiple big tradeshows and several customer engagements as we scale our go-to-market to enterprises worldwide.
This week we are participating at VMworld a very key player in the private cloud space, the king of all things virtualization and making strong inroads into network virtualization, software defined data centers and hybrid clouds in general.
Team Quali had a strong presence here with our booth getting strong foot traffic and resulting in numerous conversations on how we could help solve what's today a really big problem in the industry around automating the "first mile" of DevOps on making the Dev/Test cycles more agile and efficient. This is where Quali's cloud sandboxes kick-in saving cost and accelerating time to market - automating the workflow for the full-stack including physical and virtual infrastructure as well as applications and data modeling. Customers around the world - public cloud providers, service providers, technology vendors to enterprises are deriving benefits of this solution, as they abstract complexity and simplify their workflows.
Recognizing this, Quali was selected for the Best of VMworld Finalist Award in the category of Agility and Automation. With every enterprise adapting to the pace of change, agility with automation is becoming a practical way to achieve competitive differentiation. We feel this recognition at VMworld amongst hundreds of vendors exhibiting is a great validation of the innovation and value proposition that Quali brings to the table.
Best of VMworld - Finalist award for Agility and Automation
Quali booth get swamped - "What is the cloud sandbox. How can it automate the workflow for my Dev/Test environment ?" is the most common question asked. Customers were also interested in how Quali could help scale BizOps use-cases - Demos, PoCs, Training Labs. Quali sandboxes are very malleable. So we asked them "What do you want your sandbox to be?".
We're keeping busy the rest of the year and dialing up the momentum. Quali will be at Jenkins World in two weeks. My comrade Hans Ashlock gives you a sneak peek of what we're up to there.
And if you're a DevOps enthusiast, please join us in this webinar - Demystifying DevOps - on Sept 14th. It'll be a great educational experience with the formidable duo of Joan Wrabetz and Edan Evantal joining me as I host the session. Click to Register here.
With cyber-attacks on the ascent, the need to strengthen the security posture and be responsive is top of mind for CIOs, CEOs and CISOs. Security is very closely interlinked to all aspects of the business and has a direct bearing on business reputation, privacy and intellectual property. Unfortunately, the IT stack continues to get complicated even as attacks continue to get sophisticated. Further artificial simulations undertaken without a real-world replica or a virtual-only scenario can often overlook vulnerabilities that could not be seen in a simulated environment. And in the cases where an investment is made in building the complex testing infrastructure, it can often be cost prohibitive aside from the time spent to set up and tear down infrastructure and applications. This is where traditional security test beds run into bottlenecks, as they require significant, costly investments in hardware and personnel—and even then cannot scale effectively to address today’s growing network traffic volume and ever-more-complex attack vectors. Government, military, and commercial organizations are deploying “cyber ranges,” test beds that allow war games and simulations to strengthen cyber security defenses and skills.
Quali has always been involved in making these test beds highly efficient, cost-effective and scalable. Over the last few years Quali’s flagship product CloudShell has provided the ability to replicate large scale, complex and diverse networks. It can orchestrate a hybrid sandbox containing both virtual and physical resources needed for the assessment of cybertechnologies. Because cyber ranges are controlled sandbox, CloudShell resource management and automation features provides the ability to stand up and tear down cyber range sandbox as needed in a repeatable manner. Operational conditions and configurations are easily replicated to re-test cyber-attack scenarios. This sandbox utilizes resources such Ixia BreakingPoint, intrusion detection, malware analyzers, firewall appliances, and common services such as email and file servers. The sandbox resources are isolated into white, red and blue team areas for cyber warfare exercise scenarios in a controlled sandbox.
Today we announced how we took this capability a step further in association with Cypherpath to provide containerized portable infrastructure to support virtual sandboxes and cyber agents. Through this partnership, joint customers can use on-demand containerized infrastructures to create and manage cyber ranges and private cloud sandboxes. Through full infrastructure and IT environment virtualization and automation, security conscious enterprises can save millions of dollars in costs associated with creating, delivering and managing the full stack of physical compute, network and storage resources in highly secure containers.
One such customer is the United States Defense Information Systems Agency (DISA) the premier combat support agency of the Department of Defense (DoD). According to Ernet McCaleb, ManTech technical director and DISA Cyber Range chief architect this solution provided them with the means to fulfil their mission without sacrificing performance or security and deliver their MPLS stack at a fraction of the cost.
Cyber Ranges are not just for federal defense establishments alone. They have broader applicability across the Enterprise.
Top 3 Reasons to use Cyber Ranges
3 questions to consider for choosing Cyber Ranges or sandbox infrastructure solutions
Teams from Quali and Cypherpath have developed a joint solution brief that can be accessed here.
Finally, as an interesting side note, CloudShell’s capabilities allowed system integrators like TSI to model tools like Cypherpath in. This becomes important as the modern IT landscape continues to evolve and allows not just security professionals, but DevOps teams, cloud architects and other system integrators to leverage the standards-based approach CloudShell has taken towards its “shells” including its open source initiatives.
As enterprises bring newer security tools into their arsenal against cyber-attacks, the modern cyber ranger solutions from the likes of Quali and Cypherpath should definitely be on top of their consideration list.
It has been a little over a month in the midst of a hot and sunny California summer since I joined Quali.
Lior, my boss and Quali CEO, was scheduled to travel in early July soon after I joined. Wanting to ensure we spent some quality time before he left, he set up a meeting with the subject “Drinking from the Firehose”. We spend a couple of hours doing deep dives which was incredibly useful to me. Since then, I’ve gotten pulled into numerous meetings, met several new colleagues, customers and partners. It has been tremendous learning. But if he were to set up another meeting today, a month down the line, and used the same meeting subject line, I bet it would still be apt. I’d still be drinking from the firehose.
In some ways, what I feel is isn’t just what “newbies” on the job experience. It is representative of the industry at large. Everyone is drinking from the firehose. And not just the traditional IT industry. Financial services, retail, healthcare, transportation and even, yes, government are all experiencing the winds of change as they look to technology for differentiating themselves. The only thing constant is change.
Not surprisingly, many equate change with disruption. Businesses with “cash cows” shudder at making changes that jeopardize their revenue stream to move in new directions that don’t have guaranteed outcomes, and risky bets may need to be place. But status quo is often not an option as Blockbuster, Kodak and Borders will all bear testimony.
Other are more willing to embrace change and place new bets with a promise to “fail fast” if those bets don’t work out. Status quo is NOT an option for them. It is fair to say their odds of staying relevant increase tremendously benefitting both their employees and customers. Some are even bolder willing to consciously disrupt themselves or parts of their business before they’re forced to do it. They end up both leading the way and serving as agents of change.
Fortunately, many of Quali’s customers fit in the latter bucket. They’re tremendous innovators using technology as a core differentiator and willing to re-invent themselves. Suffice to say Quali is in the same mold, having re-invented itself a couple of times, focusing on “where the puck is going rather than where the puck is”. This is reflected in its marquee customer base of several of the Global 100 and beyond.
Visiting Cisco Live in my second week at Quali in the desert sands of Las Vegas proved to be quite a revelation. In some ways it was like a home coming, as I am a Cisco alumnus, but it also gave me an opportunity to see things from an outside-in perspective. To its credit Cisco has stayed at the pinnacle of the networking industry for decades as it has continued to re-invent itself time and again. When asked a few years ago, at the peak of the SDN hype, when investors though that Cisco was too big to move quickly, I had responded that “Cisco had the wisdom of an elephant but agility of a cheetah”. Despite being a giant, it embodied the spirit of a startup in many ways. Fast forward to now, I can see Cisco still doing that, as it is placing emphasis on attracting new buying centers, making network and other infrastructure elements more open and the huge strides it is making in reaching out to the developer community, which a few years ago would have nothing to do with Cisco. In fact, Cisco DevNet is an outstanding example of the company placing a bet on how developers can engage with infrastructure “sandboxes”. These sandboxes have truly abstracted a lot of the underlying complexity and given tens of thousands of developers a playground that lets them imagine the possibilities of infrastructure as code.
The applicability of sandboxes goes beyond self-service portals for developers to engage in. Today, the pace of change has dictated that development organizations move quickly to meet the needs of the business. While speed is valued, being reckless is not. This is where the whole movement of DevOps becomes strategically important. DevOps adds value and brings operational rigor to development organizations while still allowing them to move quickly with reduced risk. But DevOps is not an “on/off” switch that can be turned on overnight. It is a journey and requires discipline to build processes that can scale over time.
Sandboxes can help smoothen the DevOps journey, particularly during what I call as the “first mile” of DevOps around automating the Dev/Test aspects of the lifecycle, especially where real-world replicas of production environments need to be created quickly. It can also have applicability in enabling ecosystems, building portals for sales and marketing to deliver training, proof-of-concepts or demos that are configured on the fly.
Quali has evolved into becoming a leader for sandboxes that enable DevOps and BizOps automation. Its architecture brings the ability to model, orchestrate and deploy portable environments that for the full stack – physical and virtual infrastructure as well as applications on-premise and across private, public and hybrid clouds. Customers that are planning for cloud migration, application modernization, digitization or embracing the Internet of Things (IoT) – all benefit from having increased rigor and automation during the DevOps journey.
As summer starts to wind down, I’m due to visit the desert sands again at VMworld. Quali will be present there.
I’m sure I’ll still be drinking from the firehose – and loving it!