Tag: AWS

  • Why You Need Chaos Engineered into Your Hybrid Cloud Infrastructure

    Why You Need Chaos Engineered into Your Hybrid Cloud Infrastructure

    Nearly a decade ago, I began working at Amazon as an engineer. Cloud technology was just starting to revolutionize how companies launch applications, and early adopters were seeing the benefits of not having to purchase, provision and manage their own hardware. On the flip side, larger companies (especially those that store sensitive information) were still hesitant to fully embrace the black box that was “the cloud,” holding onto the belief that for critical applications, the cloud was neither reliable nor secure.

    Fast forward to today, and all of that has changed. We are seeing government institutions, banks, and hospitals all moving their infrastructure over to the cloud. The benefits of being agile, innovative, and highly efficient have mostly overshadowed the concerns around the cloud’s reliability. According to Cloud Technology Partners, cloud adopters see an average reduction of total cost of ownership (TCO) of around 40 percent. And top-performing banks are 88 percent more likely to implement a hybrid cloud solution than their underperforming peers, cites a recent report from IBM Institute for Business Value.

    Long story short, the question is no longer “if” but “which”—and there are three major options: AWS, GCP and Azure. Today, many companies are doing their best to avoid vendor lock-in, opting instead for a distributed strategy, where teams are empowered to choose the best option for what they are working on. While having a hybrid approach helps avoid vendor lock-in, it also can save teams from disaster if one of the cloud providers has a major outage like the great S3 outage of 2017.

    But just because you have a hybrid strategy—running active-passive across different cloud providers—doesn’t mean you’re home-free. Unless you’ve actually tested that your passive stack will jump in to save the day in the event of a crisis, you’re more or less closing your eyes and crossing your fingers in the hopes that your active stack never goes down. Think of it like running a fire drill: How can you be sure everything runs smoothly during a time of disaster if you never actually run the drill?

    We need to shift how we think about operations to place more of the burden of Ops work upfront. While it’s important to reduce MTTR (mean time to resolution), that still means there has been an incident that has affected customers and potentially your bottom line. As someone who has been a call-leader for Amazon and Salesforce, I know firsthand that we could save ourselves a lot of headaches by being more proactive about running experiments in a controlled environment and focusing on reducing the MTBF (mean time between failures).

    This is why it is important to have a chaos engineering solution that can run experiments across all of your environments regardless of their build, technology or provider in one simple to use, unified experience. By consistently testing that your “failsafe” actually behaves the way you want it to, you can be much more confident that the operations work you’ve put in to make your architecture more resilient isn’t all for naught when a real-world outage comes calling—and it will.

    — Matthew Fornaciari

  • 5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    Ok, so you’re probably more excited about topics such as microservices and containers right now, but bear with me. AWS Service Catalog is becoming increasingly necessary as cloud infrastructure evolves, allowing IT and developers to share pre-approved services, which helps tear down silos and encourage DevOps-related practices.

    If you’re not familiar with Service Catalog, it allows organizations to create, manage and share catalogs of IT products and services that are approved for use on AWS. You can share simple services, such as an Amazon S3 bucket, or more complex services, such as a multi-tier application containing an auto-scaling group and Amazon RDS with Amazon DynamoDB tables. Amazingly, the end user can provision these services without knowing the complexity behind the AWS services, and if you wanted, without needing write permissions to AWS (more on this later).

    Further, Service Catalog is built on top of AWS CloudFormation, which means that when you design services and follow security best practices and run time, you can add constraints such as controlling instance sizes (I know, everyone loves to launch the biggest instances).

    In this blog post, I’ll share five reasons why you should consider making Service Catalog part of your DevOps and cloud strategy right now.

    Improved Security

    As a sysadmin 10 years ago, I remember our department had full control of bringing all new resources to the infrastructure. We’re fortunate that’s no longer the case and its typical for developers to provision resources.

    Provisioning resources on AWS has never been easier, but many developers who can provision resources have limited understanding of the AWS shared security model. For example, a recent Uber hack was due to someone checking the keys to GitHub. What’s more, the steady and impressive flow of new services from AWS makes it even more difficult to know and follow security best practices for provisioning resources for various services.

    Service Catalog can help improve security. Here’s how:

    • Have developers provision resources without having access to AWS. Yes, you read that right: You can add constraints regarding which IAM role should be used to provision resources.
    • Build your service catalog on top of CloudFormation, which means you can follow the security best practices once, such as enabling data encryption at rest encryption for S3. So, when your users provision resources, all these best practices are applied.

    Cost Savings

    In Service Catalog, you can add constraints on the size resource allowed for provisioning (love the extra-large instances). Your developers can still provision resources, but they’re not going to break the bank. And your CFO will love you for that.

    Using constraints you can control instance type to be either t1.micro or m1.small

    Centralized Management of Service Catalog Across Accounts for Better Compliance

    Although Service Catalog is built on top of CloudFormation, unlike CloudFormation it’s designed for sharing commonly deployed applications to promote collaboration. This means you can share the service catalog across multiple accounts and have the same constraints copy over. Here’s a great article on how to do that.

    Productivity Gains

    Most often I work with companies on Service Catalog to increase productivity. One of the common objections I get is, “We’re not ready for this level of standardization because our infrastructure is changing so fast—we’re in rapid change mode.” Fair enough! However, even during this rapid development phase, your developers are most likely, individually rather than collectively, working on standardization to increase productivity. As an example, let’s say I normally launch a test server that updates the security group with access to VPN. Chances are there are other developers taking similar actions by writing their version of scripts. This is precisely where Service Catalog helps, by providing the platform to share these types of services (such as launching a server with VPN access only) to other employees, which, in return, improves team productivity.

    Facilitating DevOps Culture

    A principal objective of DevOps is to break down silos and align team members around delivering customer value. Service Catalog encourages a culture of sharing and collaboration by instantiating it into practice.

    What’s Next?

    I’m excited about the capabilities of Service Catalog and its promise for DevOps teams. At nClouds, we’re taking our use of Service Catalog to the next level by integrating an approval process to govern provisioned services, and automating the workflow as part of the change management process. Automation and just-enough lightweight process provide the control needed, but without sacrificing DevOps speed. You can read more in this new white paper, “Modern Change Management for AWS.”

    Also, for more information about Service Catalog and DevOps in practice there are some great presentations from AWS re:Invent available for replay: financial services FSV308, Fannie Mae MSC201, and John Wiley & Sons DEV321.

    — JT Giri

  • DevOps Primer: Using Vagrant with AWS

    DevOps Primer: Using Vagrant with AWS

    One of the most common problems in modern software development is the phrase, “It works on my machine,” when a particular piece of code runs on developer’s machine but produces error on other team member’s machine. Thankfully, now there is a plugin that can help determine why something works only in particular environments, turning the phrase into more an observation than an excuse.

    Vagrant to the Rescue

    Vagrant is a tool for building and maintaining portable software development environments. It isolates your project’s dependencies and configuration from your projects without disturbing the tools your application is consuming. You could easily reproduce similar environments on other machines by using the same configuration as your machine.

    Basic Concepts in Vagrant

    Before going further, it is important to understand the following basic concepts that are essential to the working of Vagrant.

    Provisioners

    Provisioners provide automation for installing different software and configurations. It is useful in cases when you don’t want to install software manually to your machine.

    Providers

    Providers provide basic services that are required to run your machine. Although Vagrant provides support for VirtualBox, Hyper-V and Docker, other providers can also be used through appropriate plugin.

    Boxes

    Boxes are Vagrant environment packages that can be copied to any other machine to replicate a similar environment. Vagrant provides a repository of these boxes that can be downloaded, and you can contribute to the list by adding your own customized box.

    Install the Plugin

    The first step in the process is to make sure that you have Vagrant installed on your machine. As I mentioned earlier, you could use providers by installing the respective plugins. For the purpose of this tutorial, I will download the vagrant-aws plugin through the following command:

    vagrant plugin install vagrant-aws

    Next, verify the plugin installation through the command:

    vagrant plugin list

    The vagrant-aws plugin should be present in the plugins list

    Set Up the Vagrant Box

    After installing plugin, the next step is to install a Vagrant box. The problem is that there is no box for AWS provider. To make things work, I recommend you use the dummy box provided by Mitchell Hashimoto.

    Run the following command to add the dummy box:

    vagrant box add aws https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

    Although I have named the box aws, you can give it any name that works for you. Once the process finishes, I am ready to create AWS instances.

    Create the Instance

    Run the vagrant init command to create a vagrant file:

    vagrant init

    Next, edit the vagrant file as follows:

    # -*- mode: ruby -*-
    # vi: set ft=ruby :

    # Require the AWS provider plugin
    require ‘vagrant-aws’

    # Creating and configuring the AWS instance
    Vagrant.configure(‘2’) do |config|

    # Use dummy AWS box
    config.vm.box = ‘aws’

    # Specify configuration of AWS provider
    config.vm.provider ‘aws’ do |aws, override|
    # Read AWS authentication information from environment variables
    aws.access_key_id = ‘ABCR2NDJKZJIAJ5QVXGJK’
    aws.secret_access_key = ‘WAuZE39lKHXAJnCfbZf2y6DzRfeCsPUU/yZMRDWo’

    # Specify SSH keypair to use
    aws.keypair_name = ‘vagrant’

    # Specify region, AMI ID, Instance and security group
    aws.region = ‘ap-southeast-2’
    aws.ami = ‘ami-14b55f76’
    aws.instance_type = ‘t2.micro’
    aws.security_groups = [‘default’]

    # Specify username and private key path
    override.ssh.username = ‘ubuntu’
    override.ssh.private_key_path = ‘~/vagrant/vagrant’
    end
    end

    Vagrantfile Explained

    The following list explains the important variables and aspects of the above file:

    • config.vm.box : Specify the box. Using dummy aws box for AWS deployment
    • aws.access_key_id : Access key ID of your Amazon account
    • aws.secret_access_key : The secret access key for your Amazon account
    • aws.keypair_name : Your SSH keypair in AWS
    • aws.region : The AWS region in which you want to create your instance
    • aws.ami : The AMI ID you want to use. AMI specifies the information needed to launch a virtual machine within EC2
    • aws.instance_type : The AWS instance you want to create
    • aws.security_groups : Specify the names of security groups that will be applied to your instance
    • override.ssh.username : The username that will be used to access the instance
    • override.ssh.private_key_path : The path of your SSH private key

    Launch the Instance

    After configuring the Vagrantfile, I will simply run the vagrant up command. Vagrant will launch an AWS instance through the AWS AMI provided in the configuration using the credentials provided in the Vagrantfile.


    You can view the newly created instance in the AWS console panel.

    You can now SSH into your AWS instance or perform other Vagrant operations.

    Final Words

    As you can see, using Vagrant to launch a AWS instance is simply a matter of installing the plugin and then launching the instances through easy steps. If you need help with the process, do leave a comment below.

    About the Author / Ali Azmi

    Ali Azmi is Associate DevOps Engineer at Cloudways – A Managed PHP Cloud Hosting Platform. He is skilled in developing PHP applications particularly in Laravel. He is passionate about contributing to open source projects.

  • How Data Drives the Business of a Clean Energy Company

    How Data Drives the Business of a Clean Energy Company

    Imagine using kerosene lanterns to light your way into the evening, at home so you can cook, read, shower and the kids can do homework, or outside to keep a business or medical center open or play night games in a park or field. This is life in undeveloped nations. Not only is the light source insufficient, but burning kerosene is harmful to individual health and pollutes the air.

    These issues are important to the team at BBOXX, a new generation utility company that develops clean renewable solar energy products for developing countries. Its team has developed its own “Battery Box,” a solar-powered battery box that powers lights and appliances for rural Africa—providing clean energy for numerous products and appliances including TVs, lamps and mobile phones and any other item that lights up or needs to be powered.

    BBOXX describes itself as a service company, not a technology company, and as such focuses on being a data-driven company, capturing customer data, analyzing and manipulating it to provide better services and to continue to improve the battery box.  Customer data is critical to its overall success: Knowing how and why customers buy and use the battery, when they use it, length of time … there are a number of data points that help BBOXX understand the customer. In addition, BBOXX needs to monitor the batteries to ensure they’re working properly, help maintain connectivity and disable units, if need be.

    BBOXX’s development team captures data by remotely monitoring units. They are able to access data that is being sent from sensors via a 2G network and through the Amazon Web Services infrastructure into the cloud. Once the raw sensor data is in AWS, it is then stored in a database designed for metrics and events. From here, they are able to analyze it, provide business dashboards, generate predictive maintenance alerts and notifications and predict and find interesting business trends such as energy consumption spikes during soccer events, for example.

    In addition, the team at BBOXX can also correlate and aggregate usage information, which helps them upsell additional power capacity based on upcoming events. For example, a football match between Kenya and Zambia increased demand for more energy to support extended viewing times.

    Becoming a data-driven business meant that BBOXX needed access to real-time data at its core, which had another set of challenges:

    • Securely monitor a distributed set of devices across low bandwidth 2G networks
    • Provide real-time 24-7 monitoring to a distributed team who expects the data to always be right and available
    • Provide the ability to monitor and react to high-speed time-series data
    • Ability to remotely monitor and manage the distributed devices
    • Ability to track usage statistics and bill based on these statistics
    • Proactively monitor units so they could be repaired before the customer lost power
    • Provide insight into customer usage patterns to develop compelling pricing plans
    • Gather, harmonize and use three different sets of data from the various components:
      • Raw telemetry data (voltage, current, temperature)
      • Logs from the box firmware
      • Derived data (power, daily energy usages, state of charge)
    • Lack of staff to manage another solution
    • Keep latency systems at a minimum – their systems were already hosted in AWS and the performance was meeting the needs of the company

    BBOXX is now able to gain insight into its data and apply lessons learned from analyzing past data to develop new and exciting products. The company now uses data stored in a whole new way:

    • Developers ​analyze the data for ways to create new data streams
    • Analysts look for irregularities in usage and write algorithms to detect alerts
    • Business managers look for customer usage patterns
    • Technicians analyze time series voltage and current patterns for remote diagnostics
    • Centralized call center operators reconcile more technical issues for customers by seeing the reason for the outage (hardware failure, over-usage, non-payment)

    In addition, their investors are highly interested in their data collection and analysis as a marker for competitive advantages, reduced delinquencies, growth potential and decreased risk.

    BBOXX uses Amazon Web Services (AWS) to receive store and analyze its steadily increasing portfolio of products. By designing its software architecture with scalability in mind, BBOXX takes advantage of a wide range of AWS’s integrated features including load balancing, auto scaling groups and code deploy to maintain fast, reliable and consistent access both internally and externally.

    Without access to user data, BBOXX would not be able to offer the unique services it does today, which is a fully vertically integrated service, controlling every part of its customer experience.

    About the Author / Mark Herring

    Mark is a zealous marketer who believes that the road to marketing success always leads with the developer. Before InfluxData, Mark was VP of corporate marketing and developer marketing at Hortonworks, SVP of Products at Software AG, VP of Middleware, Java and MySQL Marketing at Sun Microsystems, and VP of Marketing at Forte Software. Earlier in his career, Mark was a developer and technical support engineer for Oracle. Mark holds a B.S. Degree from the University of Witwatersrand, South Africa. Connect with him on LinkedIn and follow him on Twitter.

  • Trend Micro Expands DevSecOps Portfolio

    Trend Micro Expands DevSecOps Portfolio

    At the AWS re:Invent 2017 conference today, Trend Micro significantly expanded its reach into DevSecOps by announcing it has acquired Immunio, a provider of agent software that can be employed on a central platform engine to execute security policies on a granular level.

    In addition, Trend Micro announced it is adding support for container image scanning to its portfolio of security products as well by the spring of 2018.

    Mark Nunnikhoven, vice president of cloud research for Trend Micro, says both the Immunio policy engine and the container image scanning technology are now part of the Trend Micro Hybrid Cloud Security family of offerings that the company plans to expand for developers. Those capabilities, in turn, are exposed to developers deploying applications on-premises or in a public cloud primarily through its Trend Micro Deep Security cloud service, a suite of security technologies and threat detection services exposed by application programming interfaces (APIs).

    Nunnikhoven notes Trend Micro has seen a significant increase over the last several years in the use of programmatic approaches to managing security. Most of the shift has been driven by developers who have driven security to the left as part of the rise of DevSecOps. But he says security professionals are also starting to develop programming skills to advance IT security both in the cloud and on-premises.

    Nunnikhoven says the rise of containers is making DevSecOps more challenging. Too many developers are still grabbing containers from registries without checking them for vulnerabilities. As many as one-third of containers may contain known vulnerabilities, he says. To address that issue, Gartner estimates that by 2019 more than 70 percent of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages. That compares to less than 10 percent in 2016.

    IT organizations, however, don’t just want to be able to scan container images. Nunnikhoven says it’s clear they want a set of integrated security tools that can be employed to secure both the containers and the hosts they are deployed on. In the case of Immunio, Trend Micro is adding a security technology that can be embedded in applications running on virtual machines or bare-metal servers, as well as containers making up a microservice.

    While Trend Micro has a long history of providing security products to IT and cybersecurity professionals, it and virtually every other security vendor are competing against a host of startups that have embraced DevSecOps to change how security technologies are consumed. In its effort to remain relevant, Trend Micro is expanding its portfolio of products to focus more on developers. Over time, however, Nunnikhoven expects there will be increased collaboration between developers and IT security professionals, as the lines of responsibility for various aspects of security are better drawn.

    In the meantime, however, Trend Micro—like most of the vendors in the IT security industry—is now clearly making a hard shift to the DevOps left.

    — Mike Vizard

  • Case Study: DevOps Key to AWS Cloud Migration

    Case Study: DevOps Key to AWS Cloud Migration

    DevOps practices halved the time it took this SaaS company to migrate to AWS

    Australia-based Whispir provides communications applications as a service. One of its goals is to get products into users’ hands as soon as possible, and that requires development, operations and product staff working together, said Jonathan Swift, head of product and operations.

    Whispir formerly operated from a co-location data center, a model that continued as it expanded internationally. But the time and effort needed to run the systems was not cost-effective for an organization of its size, so the company switched largely to AWS. Governance issues faced by some clients force the company to still run its own systems in certain geographical locations.

    In the process, “[We] learned a lot about our app and how to make it cloud-ready,” said Swift. “Cloud isn’t free, cloud isn’t cheap” and is potentially more expensive than placing servers in co-lo data centers if the software isn’t built correctly.

    For example, it makes sense to make the most use of a physical server as it is largely a fixed cost. But in the cloud, the fewer resources you use, the less it costs.

    Crises Lead to Spikes

    On the other hand, a lot of Whispir’s business is crisis-focused (eg, Caltex uses Whispir at its Kurnell oil refinery in Sydney to send emergency messages), and it takes a certain amount of time to spin up additional instances to deal with spikes in message volumes. “That was a real challenge,” said Swift.

    Those crisis-communications clients expect Whispir to have sufficient resources to meet sudden demand. That’s an expensive proposition with co-located hardware, whereas Ccloud resources can be scaled up quickly, though not instantaneously.

    Seasonality has to be taken into account. One relatively predictable driver of crisis messaging is Australia’s bushfire season. Unfortunately, this overlaps Christmas, which is a peak time for marketing messages. So Whispir plans to run at around 200 percent of its normal baseline capacity during the fire season. This is easily done with cloud infrastructure, which Swift describes as “a beautiful thing” in this context.

    Some organizations are scared by multi-tenant environments. The ability to stand up dedicated instances on AWS is a great feature that Whispir can offer, especially to its clients in the financial sector.

    The company’s DevOps practices had been focused on the co-location environment, so even though kanban still “works very well for us” after moving to AWS, some previous choices had to be revisited. In particular, new monitoring tools were needed to cope with the elasticity inherent in the cloud and because the focus expanded from the hardware to the whole stack.

    Selected tools included the Zabbix open-source monitoring platform and Sumo Logic for trend analysis.

    Earlier this year, Whispir moved all of its Australian customers into a “pure AWS” environment. There are some great tools for migration, Swift said, “but it’s not as straightforward or seamless as you might think.” He recommends doubling any initial estimate of the time required for such projects.

    There were some nasty surprises: The first month’s bill from AWS was “huge” and it took a couple of months to determine the cause, even with the aid of AWS’s “really beneficial” premium support service.

    Security requirements in various jurisdictions had to be taken into consideration, with updates to various procedures to ensure the new cloud environment was compliant. For instance, the procedures required when a physical system was decommissioned were well-understood, but how could they be translated into a cloud environment? One specific example is that an in-house storage device can be destroyed when it reaches the end of its life, but in the cloud it’s largely a matter of relying on the provider’s controls.

    Avoid Lock-In

    But Swift warned that “the challenge is to not lock yourself in” to a particular cloud provider. For Whispir, which operates a mixed cloud/on-premises environment (no cloud provider offers the right onshore facilities in New Zealand and the hardware that Whispir has installed in Singapore is too new to be replaced by IaaS), that is a requirement rather than a strategic choice.

    Whispir would have avoided AWS-specific features that would make the platform easier to use and more difficult to get out of, despite the fact that using provider-specific toolsets can yield significant cost savings.

    Whispir is keeping an eye on Azure—”great tools, great partnerships, great ecosystems,” observed Swift—and may migrate to Microsoft’s cloud in around 18 months.

    A particular advantage is that Azure Stack can be run on private hardware, which could be useful if Whispir decided to enter a market where Microsoft Azure wasn’t present.

    Either way, the intention is to go 100 percent cloud to the extent that is possible.

    ‘Infrastructure as Code’ Means More Power for Ops

    The move to the cloud has made Whispir’s operations people more powerful, he observed. The infrastructure-as-code concept allows for rapid deployment, enables operations to contribute more to product development, reduces risk and enables the company to be more responsive to the market.

    Furthermore, dealing with on-premises hardware still very much a waterfall situation, thanks to the delays and dependencies involved. But moving to IaaS means infrastructure issues sit comfortably within the kanban model.

    IaaS also means that various network-related tasks simply disappear, but other issues arise in their place. For example, some external services used by Whispir (eg, SMS gateways) require the use of VPN connections from a known IP address, but with cloud infrastructure the best you may be able to do is specify a range of addresses. Whispir’s short-term fix was to route such connections through a specific server in the co-lo center, and in the longer term it found providers with less-restrictive arrangements.

    Moving from co-lo to cloud would have been “incredibly hard” without DevOps, Swift said. It would have taken at least twice as long, he noted, and the company wouldn’t be able to run the mixed environment as well as it does.

    “There’s no way we would have been so successful” without DevOps, he said.

    — Stephen Withers

  • Platform9 Brings Workflows to Serverless Computing

    Platform9 Brings Workflows to Serverless Computing

    Serverless computing frameworks are widely regarded as the next big thing in enterprise IT because they are based on an event-driven architecture that makes servers, storage and networking resources dynamically available as needed using a programming construct known as functions. But DevOps teams are challenged in finding a way to orchestrate all those functions in concert with one another.

    To enable the orchestration of those functions, Platform9 has added support for Fission Workflows to its instance of a serverless computing framework. Platform9 CEO Sirish Raghuram says Fission Wokflows will make it possible for IT organizations to craft complex applications made up of thousands of functions.

    On the one hand, serverless computing frameworks promise to make DevOps easier by eliminating the need to provision infrastructure every time a workload exceeds whatever amount of capacity that has been assigned to it. On the other hand, attempting to manage what could easily become thousands of functions in an IT environment is likely to make DevOps even more challenging than it is today. While not a new concept, Raghuram says Fission Workflows provides IT organizations with a familiar construct for managing functions.

    Benefits of Fission Workflows include an ability to reuse functions as well as being able to upgrade entire related sets of functions all at once. There are also fault-tolerant capabilities that make possible to recover and restart a workflow in the event of an infrastructure failure.

    Platform9 is specifically making the case for a serverless computing framework based on Kubernetes clusters that can be deployed on-premises or in the cloud. Platform9 also provides support for containers on an instance of Kubernetes, and Raguham says the company expects that IT organizations will mix and match containers and serverless computing frameworks as they see fit. For example, a container might invoke a function via an API call to run a stateless process while Docker containers are employed for all the stateful processes that require access to primary storage, he says.

    Raguham notes the trouble with serverless computing frameworks put forward by cloud service providers such as Amazon Web Services (AWS) is that they lock an IT organization into a specific platform instead of taking advantage of a portable cluster technology such as Kubernetes, which is backed by the Cloud Native Computing Foundation (CNCF). Kubernetes also provides the added benefit of a common platform for both containers and serverless computing, he says.

    It’s still early days for the use of serverless computing frameworks in the enterprise. Nevertheless, it’s clear they will need to be managed from a DevOps perspective alongside cloud-native applications running on containers and platform-as-a-service (PaaS) environments and legacy applications running on virtual machines and bare-metal servers. Given the fact that none of these architectures is likely to supersede any of the others anytime soon, IT organizations would be well-advised to start crafting a DevOps strategy now on the assumption that the overall IT environment is about to become even more complex.

    — Mike Vizard

  • With a Multicloud Infrastructure, Control is Key

    With a Multicloud Infrastructure, Control is Key

    Ask any developer or DevOps manager about their first experiences with the public cloud and it’s likely they’ll happily share some memories of quickly provisioning some compute instances for a small project or new app. For (seemingly) a few pennies, you could take full advantage of the full suite of public cloud services—as well as the scalability, elasticity, security and pay-as-you-go pricing model. All of this made it easy for teams to get started with the cloud, saving on both the IT budgets and infrastructure setup time. Public cloud providers AWS, Azure, Google Cloud, Rackspace and others made it easy to innovate.

    Fast forward several years and the early promise of the cloud is still relevant: Services have expanded, costs have (in some cases) been reduced and DevOps teams have adapted to the needs of their team by spinning up compute instances whenever they’re needed. But for many companies, the realities of their hybrid-IT infrastructure necessitates support for more than one public cloud provider. To make this work, IT Ops needs a control layer that sits on top of their infrastructure, and can deliver applications to customers over any architecture, including multicloud. This is true, no matter what the reason teams need to support multi-cloud environments.

    Prepare for the Worst

    As any IT Ops manager, or anyone who has lost access to their web app knows, outages and cloud service degradation happen. Modern Ops teams need a plan in place for when they do. Many companies choose to utilize multiple public cloud providers to ensure their application is always available to worldwide customers, even during an outage. The process of manually re-routing traffic to a second public cloud in the event of an outage is cumbersome, to say the least. Adding an app delivery control plan on top of your infrastructure allows companies to seamlessly and automatically deliver applications over multiple clouds, factoring in real-time availability and performance.

    Support Cloud-driven Innovation

    Ops teams often support many different agile development teams, often in multiple countries or from new acquisitions. When this is the case, it’s likely that the various teams are using many architectures on more than one public cloud. Asking some dev teams to switch cloud vendors is not very DevOps-y. A better option is to control app delivery automation with a cloud-agnostic control plane that sits on top of any cloud, data center or CDN architectures. This allows dev teams to work in their preferred cloud environment, without worrying about delivery.

    Avoid Cloud Vendor Lock-in

    Public cloud vendors such as Amazon Web Services or Microsoft Azure aren’t just infrastructure-as-a-service (IaaS) vendors, they sell (or resell) products and services that could very well compete with your company’s offering. In the beginning, using a few cloud instances didn’t seem like such a big deal. But now that you’re in full production and depend on one of these cloud providers for your mission-critical app, this no longer feels like a great strategy. Adding a second public cloud to your infrastructure lessens your dependence on a single cloud vendor who you may be in “coopetition” with.

    Multiple-vendor sourcing is a proven business strategy in many other areas of IT, giving you more options during price and SLA negotiations. The same is true for IaaS. Cloud services change often, as new services are added or removed, and price structures change. Taking control over these changes in public cloud service offerings, pricing models and SLAs is another powerful motivator for Ops teams to move to a multi-cloud architecture. An application delivery automation platform that can ingest and act on cloud service pricing data is essential.

    Apps (and How They’re Delivered) Have Changed

    Monolithic apps are out. Modern, distributed apps that are powered by microservices are in. Similarly, older application delivery controllers (ADCs) were built for a static infrastructure world, before the cloud (and SaaS) were commonly used by businesses. Using an ADC for application delivery requires a significant upfront capital expense, limits your ability to rapidly scale and hinders the flexibility to support dynamic (i.e. cloud) infrastructure. Using ADCs for multiple cloud environments compounds these issues exponentially. A software-defined application delivery control layer eliminates the need for older ADC technology and scales directly with your business and infrastructure.

    Regain Control

    Full support for multicloud in product may sound daunting. After all, Ops teams already have plenty to worry about daily. Adding a second cloud vendor requires a significant ramp-up period to get ready for production-level delivery, and the new protocols, alerts, competencies and other things you need to think about. You can’t be knee-deep in the details of each cloud and still manage infrastructure. Adding in the complexity of application delivery over multiple clouds can be a challenge, but much less so if you use a SaaS-based application delivery platform. With multicloud infrastructure, control is key.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services and Microsoft. Connect with him on LinkedIn.

     

  • Is AWS Cloud Per-Second Billing Boon or Bane for DevOps Engineers?

    Is AWS Cloud Per-Second Billing Boon or Bane for DevOps Engineers?

    Amazon’s introduction of its AWS services in 2006 with a per-hour billing model for compute resources was a game-changer for the IT world. Since then, AWS has taken over the cloud computing market as a leader, while broadening the range of cloud services offered every year. However, the per-hour billing business model was one of the major issues for many customers—in particular, those who had applications using EC2 for only minutes at a time.

    Recently, AWS announced support for per-second billing of its EC2 service, addressing the aforementioned concerns. Of course, this also created controversy among the per-hour supporters. While I won’t get into the pros and cons across the whole enterprise, one group in particular is affected from the new per-second model: DevOps engineers.

    Here are the top five implications for DevOps teams as a result of per-second billing:

    Autoscale without worrying about cost

    Most engineers were vary of autoscaling at will, mostly because of EC2’s hourly charges even though they might need additional compute capacity for just 15 minutes. With per-second billing, DevOps engineers don’t have to worry—it’s as simple as scaling your EC2 instance as you need to, and when you need to.

    No more custom logic for hourly batches

    Many customers use EC2 for jobs and batch processing purposes. Due to the hourly pricing, engineers have written custom logic to benchmark and constantly tune the number of nodes in their batch clusters to ensure they are cost-optimized. Per-second billing frees up headaches for DevOps engineers that are using EC2 for batch processing and job clusters.

    The need to speed up EC2 launches

    With per-second billing, it’s important to take advantage of prebaked Amazon Machine Images (AMI) for launching your EC2 instances, instead of complete configuration setup on every instance launch. This will reduce the costs for you, by saving anywhere from five to 15 minutes. It’s time to create prebaked AMIs for faster instance launches, ultimately saving costs.

    Dilemma of Lambda or EC2

    Be prepared to compare whether to use Lambda or EC2 for new workloads and applications more often than you are used to. Your benchmarking between Lambda and EC2 has become a little more dicey. The serverless lambda just got competition from EC2 again.

    Your big data just got easier

    With EMR also supporting per-second billing, your job has become a lot easier. As a , you no longer need to constantly benchmark your EMR clusters for number of nodes and job processing times to be optimized for per-hour billing.

    DevOps engineers have a lot to benefit from per-hour billing, but also much to consider when it comes to time-to-deployment and choosing a compute service. Now is the the time for DevOps engineers engineers to bring these concerns to their CIOs to make a smooth transition to the new AWS business model.

    About the Author / Vijay Rayapati

    Vijay Rayapati, CEO of cloud management platform company Botmetric, identifies himself as a technology entrepreneur, passionate about creating products, building high-performance teams, and solutions that solve real-world business issues. Vijay is a popular speaker in India and the US, and has co-authored a popular book, “Learning Big Data.” Connect with him on LinkedIn and Twitter.

  • Amazon’s Macie: Machine Learning to Protect Data in AWS

    Amazon’s Macie: Machine Learning to Protect Data in AWS

    Macie is a recently launched security service from Amazon for its AWS customers. It works by identifying and classifying sensitive data such as personal information or intellectual property, continuously monitoring that data for anomalies and giving customers detailed alerts and dashboard readouts related to the access or movement of the data. Macie is currently able to protect data stored in Amazon S3, and support for additional AWS data stores will be available later this year, according to AWS.

    Netlix is an early adopter of Macie and so far has seen good results. “Since we started using Amazon Macie we’ve found that it is flexible enough to solve a range of information security challenges that would have previously required us to write custom code or build internal tools, helping us move fast with confidence,” says Patrick Kelley, cloud security engineer at Netflix.

    In addition to Netflix, Amazon lists Autodesk and Edmunds as early users of Macie.

    Amazon claims that Macie uses machine learning to automate the process of discovering, classifying and protecting data stored in AWS. Macie starts out by creating a baseline of data access behavior and then monitors for actions that might indicate risk, such as large quantities of data being downloaded, sensitive data being configured to be externally accessible or credentials being stored insecurely. Macie provides a console front end. It also delivers alerts and recommendations on how to strengthen your security.

    The results of Macie’s analysis of your data may help you better understand where sensitive information is stored and how it’s typically accessed, including user authentications, locations and times of day. It can identify data with high business value, including programming languages to detect source code, logging formats, database backup formats, credentials and API key formats. This is one of its more powerful benefits. Anything that helps you understand your data is a major plus.

    Amazon’s new AWS security service supports 20 alert categories designed to provide early warning on security and compliance use cases, such as high-risk data events, API keys and credentials being stored within source code, unencrypted backups containing credentials and early stages of an attack, including behaviors indicating lateral movement, persistence mechanisms, back-door accounts and enumeration of role privileges.

    Whether Macie’s pricing makes sense for your company will depend quite a bit on the type of data you’re using in AWS. The pricing also involves the data analysis so it starts out higher as Macie analyzes your data store. On the other hand, if you are continuously adding significant amounts of new data, it may continue to get more and more expensive. Check out the detailed pricing information for some insight. Amazon lets AWS customers try before they buy Macie with this test drive. You may also find its FAQ and documentation useful in assessing the tool as well as more details about AWS security.

    Analysis

    Any enterprise application that mentions the terms artificial intelligence or machine learning in its marketing materials sets off alarm bells these days. It’s not uncommon to find that such laims are more hype than reality. Enterprise buyers, beware. But Macie’s ability to classify data in risk terms is well within the state-of-the-art of machine learning today. There are no apparent flights of fancy or flowery marketing language involved. Amazon isn’t promising unrealistic things from its new AWS security service. In fact, Macie looks promising for the many enterprises that are using AWS.

    — Scot Finnie