devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • 3 Ways IoT Developers Can Make Their Applications More Secure

    3 Ways IoT Developers Can Make Their Applications More Secure

    When the IoT was still young, IoT application developers got away with making security an afterthought, as they built prototypes and minimum viable products designed to demonstrate the different ways the IoT could be used to transform the way we work, play and live. But the IoT has matured and grown to the point where today, Gartner estimates there were 8.4 billion connected things in 2017 and forecasts there will be 20.4 billion IoT devices deployed by 2020. With this growth has come a massive increase in number and sophistication of IoT security attacks, and the need for developers to make security not just a priority, but a top priority.

    As the IoT hacks of Trendnet’s SecurView camera, St. Jude’s cardiac device and the Jeep Cherokee have demonstrated, when security is not a top priority, successful IoT attacks can cause significant real-world financial, reputational and even human damage.

    While it is impossible to make IoT applications (or any type of software) 100% secure, there are several best practices that IoT application developers can adopt to strengthen the security of their IoT applications. These best practices include:

    1. Following a set of approved cryptographic standards when building applications.
    2. Using static code analysis programs that analyze application code to identify common coding mistakes that can lead to security vulnerabilities.
    3. Instituting a vulnerability management strategy that identifies and repairs known vulnerabilities in IoT applications on a scheduled, ongoing basis.

    These three best practices will not make IoT applications perfectly protected from malicious actors. However, they can significantly reduce an IoT application’s vulnerabilities and attack surface, making it much less likely a developer’s applications will be breached, generating angry customers and negative headlines.

    Follow Approved Cryptographic Standards

    Most developers understand that, if they hope to keep IoT data safe, they should encrypt this data, especially while it is in transit from device to cloud or vice versa. Yet, faced with tight development deadlines, as well as the need to make the most of their IoT devices’ limited bandwidth and processing capabilities, some developers choose to not encrypt their data or use weak cryptographic algorithms that promise to be faster or more lightweight than others but do not provide proper levels of security.

    Experience shows taking encryption shortcuts can result in customers’ data being stolen, an application disabled or other problems. For this reason, developers need to work closely with their security teams to encrypt IoT application data appropriately, following standards and guidelines approved by internationally recognized experts such as the National Institute of Standards and Technology (NIST).

    Choosing to use such approved standards does not have a major impact on IoT application development time, performance or functionality. NIST provides developers with guidelines on how to streamline integration of encryption standards into their applications. They also offer many different standards to choose from, so developers can find one that will provide their application with an appropriate level of security without sacrificing too much in terms of performance or functionality. Yes, it does require some additional work and effort, but if IoT developers want to make security a top priority, they need to make sure they are following approved cryptographic standards.

    Use Static Code Analysis Programs

    Many developers are familiar with static code analysis programs and their ability to discover common coding errors that can lead to bugs that affect software quality. However, these programs also can identify unsafe coding practices such as the use of improperly terminated strings, pointers to freed memory and buffer indexes allowed to go past the end of the buffer. These common coding mistakes create security vulnerabilities malicious actors can exploit in otherwise functional applications.

    There are a variety of static code analysis tools available, both proprietary and open source that developers can use to alert them to coding errors that could create security vulnerabilities. Developers should research which ones best support their security and other code analysis needs, and then ensure that throughout the application development processes—and especially before deploying an application—they use these static code analysis programs to discover any coding errors that might lead to a security breach down the road.

    Again, many developers might be tempted to skip this step, since the problems revealed by the program might prevent them from deploying and commercializing an otherwise functional application as fast as they would like. But, as the examples of IoT application hacks mentioned above demonstrate, cutting corners with security can often result in major problems down the road. If developers are dedicated to delivering their customers IoT applications with robust security, they need to commit themselves to using static code analysis programs to fix coding errors that might make their applications vulnerable to cyberattacks.

    Monitor For and Repair Known Vulnerabilities

    The media pays a lot of attention to so-called zero-day vulnerabilities—those that a software vendor has no prior knowledge about. However, the low-hanging fruit for most attackers is the ever-growing number of known vulnerabilities present in the millions of software components used in IoT applications that haven’t been fixed, either because the user of the component is unaware of the vulnerability or because they have not taken action to update their application to repair the vulnerability.

    All IoT application developers should be aware of the known vulnerabilities their applications might have as result of incorporating third-party software components into their applications, be they open source components (such as a Linux operating systems and associated software) or proprietary components. However, keeping up to date on all the known vulnerabilities in an IoT application’s device firmware, operating system and other third-party software components is not simple. The enterprises that have built these software components, government agencies and other watchdogs often identify as many as 1,000 different vulnerabilities in these types of software components per month.

    Fortunately, there are resources that can help developers stay up-to-date on new known vulnerabilities. For example, the National Vulnerability Database (NVD) is a public resource operated by NIST that catalogues known vulnerabilities in all types of software components, both proprietary and open source. To ensure their IoT applications do not have any known vulnerabilities, IoT developers can compile a security bill of materials (BOM) for their IoT application—a list of all the software components and versions used in the application—and then monitor the NVD for new known vulnerabilities with these components. Alternatively, there are a number of proprietary and open source tools that leverage free APIs to query the NVD database and then scan applications for vulnerabilities either by evaluating their components’ codebases or by discerning versions of exposed services (such as DNS, HTTP/S, NTP, SSH) on network interfaces.

    However, simply being aware of known vulnerabilities does not fix those vulnerabilities. Which is why developers need to not just check for new known vulnerabilities on an ongoing basis, but also have a plan to regularly repair new known vulnerabilities with security updates. Ideally such a plan should allow these updates to be performed remotely (over the air) and automatically. Today, many consumer IoT applications already include an option to enable remote, automatic updates. The commercial IoT applications built by many developers sometimes need more coordination to enable such remote, automatic updates—but this should be the goal. In any event, even if the updates can’t be done remotely or automatically, it is essential that IoT developers have some sort of plan to deploy security updates for known vulnerabilities in their applications in a timely fashion.

    Robust Security Will Enable Future Growth of IoT

    IoT is at an important inflection point. The market continues to rapidly expand, with exciting new agricultural, supply chain, industrial, public safety, consumer and other IoT applications being launched every day. Yet, additional high-profile IoT application breaches could threaten the tentative level of trust businesses and consumers have placed in the IoT, especially as it increasingly is used to collect sensitive data or complete critical tasks.

    To strengthen trust in IoT, developers need to dedicate themselves to making IoT security a top priority. Lip service is not enough–developers need to implement IoT security best practices, including the adoption of approved cryptographic standards, use of static code analysis programs to discover coding mistakes that can create security vulnerabilities and implementation of vulnerability management strategies that regularly identify and repair known vulnerabilities in their applications. If IoT developers make security a real top priority by implementing these and other IoT security best practices, the world’s trust in the IoT will grow and so will their business.

    — Larry LeBlanc

  • Top 5 AWS Security Mistakes: Leaky S3 Buckets

    Top 5 AWS Security Mistakes: Leaky S3 Buckets

    As we get ready to discuss our list of the Top 5 AWS Security Mistakes in the upcoming devopsy.kinsta.cloud webinar, we wanted to provide a preview of the type and depth of information we’ll be discussing. Since the most-talked about, and likely the most vulnerable, aspect of AWS security is inevitably those leaky S3 buckets, it’s a given we’ll tackle S3 first.

    In this article, we’ll dig into S3 buckets, explain how they become vulnerable, cover eight different ways they can inherently become open to the public and how to find and protect any public facing S3 data.

    The S3 Bucket

    S3 is one of the oldest services in AWS—so old that parts of it still support XML-based policies instead of the JSON you see everywhere else. S3 also has a lot of features that aren’t as commonly known or used anymore, such as allowing someone else to host put objects in your bucket yet still maintain ownership of them.

    Think of an S3 bucket as a server that can have subdirectories and files. Because S3 buckets can have a different root url (e.g. “dops.s3.amazonaws.com”) and have their own life cycle and settings, we tend to think of buckets as servers, not directories. Also, directories in S3 allow you to organize objects, but don’t have any distinct settings of their own, other than a name.

    AWS has a wide range of use cases it needs to support, which is why we have all these mechanisms. Sharing publicly, within an account, between accounts, hosting websites and so on, creates complexity. The good news is S3 always defaults to secure and private. The bad news is AWS allows human beings to use it (and therefore weaken security) and can be confusing to manage. For example, S3 supports both read and write permissions (and list, for buckets). It’s possible to have no public read but public write permissions, which could lead to people placing bad files in your directories.

    8 Ways AWS Data Becomes Public

    There are at least eight different ways an AWS S3 bucket can inadvertently become open to the public and be exposed to a data breach.

    • Bucket ACLs (Access Control Lists): This is an XML document that defines the first layer of access. By default, only the account owner has access, but this can be opened up to other AWS accounts or the public at large. Amazon recommends against using these at all, but it’s also the easiest way to make something public quickly, so we see it all the time.
    • Bucket Policies: These are super-flexible JSON policies that allow you to set things such as IP-based and other conditional permissions on a bucket. While this should be the primary way for managing public access, ACLs are the first tab and about three clicks to make something public. It’s this flexibility that leads to mistakes such as opening up to a wider range of IP addresses than intended or using a negative to block access to some IPs but inadvertently granting access to everyone else.
    • IAM Policies: These are the normal IAM permissions you use to control access throughout your AWS account. You can’t make a bucket public with them, since they only govern AWS users, but you can open up access to the bucket by authorizing another AWS service access, and then that service exposes the content.
    • Object ACLs: These are the primary object-level controls. It’s just like a bucket ACL and uses XML to allow access from other accounts or the public. Objects do not necessarily inherit bucket ACLs. You can totally make an object public even if the bucket is private.
    • Explicit IAM or Bucket Policy Statements: IAM policies and bucket policies can have explicit statements referencing the object, which will override the object ACL (if you own the object), since they are evaluated first.
    • Pre-Signed URLs: These object-level policies must be created using code (not the console) and provide temporary access for anyone with the URL. It’s used, for example, to share files for a few minutes or an hour for someone using your app to download a media file.
    • CloudFront Origin Access Identity: CloudFront is the AWS content delivery network and can serve as the front end to S3. You can create something called a CloudFront origin access identity to write an IAM policy that allows CloudFront to access the S3 content. If the CloudFront allows public access, it can access the S3 content and that won’t show in a bucket policy or ACL.
    • Cross Origin Resource Sharing (CORS) Policies: CORS is required if you use S3 in a website and don’t want the browser to break due to same site security settings. CORS in S3 won’t override an ACL or bucket policy but could mask public access in limited situations where the data is exposed in the web code through the authorized site.

    All put together, AWS evaluates IAM permissions first. Within those, the only one to make a bucket public over the web is the CloudFront Origin Access Identity. AWS then turns to the bucket ACLs and policies for any explicit deny statements. Then it looks at the object ACLs for public access. If you make an object public and the bucket policy doesn’t have an explicit deny, it is still public, but otherwise a good bucket policy will block everything. Besides, a lot of the problems are open bucket ACLs, not object ACLs.

    4 Ways to Find Your Public S3 Buckets and Protect Your Data

    What’s the best way to find public buckets? It’s relatively easy.

    1. Log into the console, click on S3 and look for the Public tag. AWS uses some advanced back-end math to evaluate all the bucket policies to figure out if something is public, which catches most of the fringe cases, but it does not show if the bucket is private and objects in it are public.
    2. Check CloudFront to see if you use any origin access identities. It’s easier to look here than in all your bucket policies (usually). This saves you from looking through object ACLs as well.
    3. Check any CORS policies, if you use them. This is the least common situation and I even hesitated to complicate this post by mentioning them.
    4. The bad news … there is no easy way to find public objects. Even finding them programmatically can be difficult if you have a large number. Also, changing a bucket ACL doesn’t cascade to the object ACLs so you need to run through and fix them one by one. However, if the bucket is locked down the attacker would need to know the full URL/name of the object to find it. It’s not perfect, but it’s better than nothing.

    That’s it. Although, if you know of any other fringe cases, please don’t hesitate to let us know. While conducting assessments, we find well over 90% of the problems are just basic bucket ACL and policy mistakes. Object ACLs are also an issue, but slightly lower risk since you need the exact URL to find them if your bucket is otherwise secured properly.

    If you are curious about the other 4 Top AWS Security Mistakes, sign up for the Aug 14 webinar.

    — Mike Rothman

  • Speaking the Language of Applications

    Speaking the Language of Applications

    I arrived early to a meeting, and the pleasant security guard at AT&T suggested I take a look at their innovation museum while I wait. Among motion picture sound technology and life-size photos of switchboard operators on roller-skates stood a transistor prototype. The transistor was invented in Bell labs in 1947, and it changed the world. Steve Wozniak considered it the greatest innovation of all time in his 2014 article.

    But almost nobody needs to think about transistors anymore. The transistor had to become transparent and abstracted, so the next generations can build great things in higher level. The transistor made a huge influence on our lives as an enabler, but if people had to keep talking about transistors it wouldn’t be possible.

    Abstracting technologies is key to advancing to a higher level, making it possible to solve real business problems.

    The language of a client-focused business is applications. If we want to make a business execute faster these days, we need to make the development and release of its applications execute faster. But one thing stands in our way: the infrastructure. Applications reside on infrastructure–they are installed on servers, bundled in containers, on cloud instances, in networks, using storage.

    If we want to speak the language of applications, we need to abstract them from the infrastructure, and make the infrastructure transparent.

    The concept of abstracting applications is what stands at the basis of every new approach to application development and release around us.

    • Containers are all about abstracting services from specific infrastructure and making them mobile.
    • Serverless takes it to the extreme.
    • Public cloud makes it easier not to worry about owning physical infrastructure.

    Technology screams, “Think applications, soon you will not have to worry about infrastructure!”

    And yet, most of us mix applications and infrastructure in an unhealthy way when we try to automate them. It is unhealthy because mixing applications and infrastructure prevents reuse of automation assets and makes it very difficult to connect infrastructure usage to a business context.

    Understanding how mixing applications and infrastructure is manifested requires looking back into the evolution of infrastructure and application automation.

    The Evolution of Infrastructure: Manual Deployment and the Inception of Its Automation

    In the beginning there was manual. We got a server; it was sitting on a shelf. We got the application artifacts, maybe on a CD or a USB stick. We installed the application on the server. Our application was ready for use. When we needed to upgrade, we went back to the shelf and installed the update on our server. It was very hard to make this operation faster.

    This is where automation of applications and infrastructure started.

     

    Behind any automation tool or standard stands a model. This model reflects how its creators originally perceived the problem they were trying to solve. It consists of the entities they defined as first-class citizens, the operations they wanted to apply on these entities, their attributes.

    “All models are wrong, some are useful,” said George E. P. Box in 1976. This is true for automation models too. Automation models are usually nice and clean when we start off. But as the problems we try to solve transform, our models need to grow and adapt. Until at some point they are not useful anymore and we need to replace them with next generation modelling approaches.

    The Configuration Management Model

    Configuration management tools such as Puppet and Chef were originally built to manage application deployment and configuration on static infrastructure. This new approach to Ops optimized manually updating applications on servers. Better network connectivity made it possible for this model to thrive, with the ability to configure applications on servers remotely.

    But within a decade we witnessed the fast rise of immutable infrastructure. Immutable infrastructure is an approach to deploying applications where the infrastructure components are replaced instead of updated. This approach somewhat pulled the rug from under the configuration management model. With each update or change, the application must be re-deployed. This forced adding dynamic infrastructure provisioning to the configuration management model. Combining infrastructure automation and immutable infrastructure concepts into the configuration management model is a difficult task, since this model was never designed to accommodate something like that.

    The Infrastructure-as-Code Model

    Pure Infrastructure-as-Code tools were built to provision infrastructure dynamically. Terraform is an example for an open source tool that does this well. This model is created with infrastructure in mind.

    Whether we look into Terraform, AWS, CloudFormation or ARM templates, we will see the infrastructure is the starting point (defining network connectivity, VM instances and services) and the applications are an implicit addition. They are artifacts that happen to be deployed on and are tightly coupled to the infrastructure. We may look at a component that says “App A” but it actually stands for “specific infrastructure with app A installed on it.”

    This seems natural, because it’s the same way it worked in the good old physical-infrastructure world: We fetch a box, we install something on it. We focus on the infrastructure, because this is our starting point. The application is the artifacts we put on the infrastructure and scripts we run after we provision it. Presumably, the application cannot live without something to be on.

    Infrastructure-as-Code tools evolved the way open tools do–their base model was extended by the community because there was a need to automate applications deployment and not just infrastructure. But it is becoming difficult to extend this model to reflect a world where applications are built to move between clustered servers, and the starting point is no longer the infrastructure, but rather the application’s requirements.

    Mixing Infrastructure and Applications

    Trying to fit infrastructure provisioning and application deployment in a single model that was originally designed for just one of them creates issues. Infrastructure is lower level than applications. Applications reside on the infrastructure. The same app can reside on different infrastructure configurations. This critical relationship is completely flattened if you mix them.

    Moreover, from a business perspective it is important to make applications explicit. It’s our product. Our website. Our mobile app. The applications need to be the center of the attention and discussion. This kind of modelling puts applications in the shade of infrastructure.

    Four Great Reasons to Model Applications as a First-Class Citizen Right Now

    The models we use today are broken, and it is time to evolve. No matter if your applications reside in containers, or on cloud instances, or include native cloud services or a mix of them. Applications should be a first-class citizen, and not some artifact installed as an afterthought on the infrastructure we started from.

    The notion that applications should be abstracted from infrastructure doesn’t eliminate all the challenges of infrastructure provisioning and application deployment, but it creates a foundation for better and more scalable automation.

    1. Achieve Application Re-Use

    Modelling applications as a first-class citizen is the only way to make applications a re-usable element throughout the development and release pipeline.

    If there’s one thing I learned in my automation journey, it is that if automation doesn’t get frequently and consistently reused, you don’t get value for your money.

     2. The Path to Multi-Cloud

    Abstracting application is also the best approach for moving application workloads between cloud providers. If everything starts from infrastructure, we need to start from scratch when we move. If our applications are abstracted and defined separately—this definition stays the same when we move, only the infrastructure changes.

    3. The Path to Breaking Silos

    The vision of Dev, Sec, and Ops all dealing with the same language (code) is wonderful. But bringing everyone to the same code pool is not always easy. Applications and infrastructure are not the same thing, even though we can code both. Mixing them makes them unnecessarily hard to build and troubleshoot. It forces us to deal with fuzzy boundaries when it comes to responsibility for this code. Basing automation on a model that organizes the world in a way the different stakeholders can understand it, can help overcome this barrier.

    4. Connect Infrastructure to Business Needs

    Infrastructure-as-Code is a huge breakthrough, but the bigger story is about making application development and release faster. This doesn’t undermine the importance of infrastructure; infrastructure is the foundation of everything. But if we want to solve business problems, we need to talk the language of the business, and that’s the language of applications. Our automation should be built in a way that reflects this.

    — Maya Ber Lerner

  • Stackery Smooths AWS Serverless Integration for DevOps

    Stackery Smooths AWS Serverless Integration for DevOps

    Stackery today announced a plug-in capability that will allow developers to build and debug code destined to run on the Lambda serverless computing service provided by Amazon Web Services (AWS) from within an integrated development environment (IDE) running on a local machine.

    Company CTO Chase Douglas said the latest Stackery tool can be dropped into any IDE, either via a Stackery VS Code Serverless Tools Plug-In that automates installation or a manual installation process, regardless of the programming language being employed. The goal is to make it easier for DevOps teams to construct workflows that include AWS serverless computing frameworks, which now are expanding rapidly, he said. In total, the Stackery tools can invoke any one of 86 AWS CloudFormation-compatible resources.

    Stackery provides a set of visual tools that make it easier to write functions for the AWS Lambda service without having to know how to create YAML files to manipulate infrastructure as code. This latest offering extends that capability to local environments, which will allow DevOps teams to work offline on their laptops and make changes without having to make every change on the AWS cloud over an internet connection. This capability does not require customers to set up a Stackery account to use it.

    Right now, Stackery is squarely focused on providing those tools for AWS environments, but Thomas said eventually those tools will be extended to other serverless computing environments.

    The goal is to provide DevOps teams with tools that make all serverless computing frameworks more accessible to both developers and IT operations teams, Douglas said.

    Serverless computing frameworks are gaining in popularity because they make it easier for developers to invoke additional IT infrastructure resources to kick off, for example, an analytics module whenever a certain event occurs within their application. That capability reduces the amount of code developers need to include in their core applications. Serverless computing frameworks are usually employed to run stateless processes for a very short amount of time, while containers and virtual machines continue to be relied on for running longer running applications. But for DevOps, that creates another layer of abstraction to include within the context of a larger continuous integration/continuous deployment workflow.

    Most organizations are already struggling with mastering the workflows they employ to manage the building and deployment of applications using containers and virtual machines, so any new abstraction layer of compute resources need to incorporate within the workflows easily if the providers of that service hope to achieve mainstream adoption among DevOps practitioners. Long-term, of course, the expectation is all these processes will be completely automated, which means developers only will have to ever worry about writing business logic.

    In the meantime, it’s likely to be a while before DevOps shops are invoking multiple serverless computing frameworks running on different clouds, much less automating them on end to end. That day, however, may not be as far off as people today might assume.

    — Mike Vizard

  • Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data is moving to make it easier to adopt and manage both Ansible and Kubernetes. Its Morpheus 4.0 update, announced today, includes a distribution of Kubernetes as well as tighter integration with the open source Ansible automation framework.

    Brad Parks, vice president of marketing and business development for Morpheus Data, said in the case of Ansible, Morpheus 4.0 will eliminate the need for some organizations to employ Ansible Tower, a web-based console and application programming interface (API) used to manage instances of Ansible. The goal is to make it easier for organizations to take advantage of the declarative Ansible automation framework without having to master all the low-level minutiae currently required to deploy and manage it, he said.

    Morpheus 4.0 also makes it possible to view real-time job status updates and detailed log output and execute phased-based and operational workflows using multiple playbooks and brings governance, auditing and reporting tools to Ansible. Morpheus 4.0 also makes it possible to configure Ansible to run over the Morpheus secure agent communication bus, allowing playbooks to be applied to instances where SSH/WinRM access may not be feasible due to security constraints. Available on both Linux and Windows platforms, Ansible also can employ that bus to query secrets securely from the Morpheus Cypher service for storing application secrets.

    In a similar vein, Morpheus Data is also moving to automate the deployment and management of Kubernetes, an open source container orchestration engine developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    By including a distribution of Kubernetes in Morpheus 4.0 that has been certified by the CNCF, Parks said Morpheus Data now makes it possible to federate the management of Kubernetes clusters across a hybrid cloud computing environment. DevOps teams can employ either the distribution of Kubernetes provided by Morpheus Data or Morpheus to provision instances of Kubernetes services provided by public cloud service providers such as Amazon Web Services (AWS), Microsoft and Google.

    Morpheus 4.0 also makes it possible to securely share and govern resources using role-based access controls, optimize resource allocation using analytic tools and audit, monitor and manage logging. DevOps teams also have the choice of provisioning applications using either Morpheus or the Helm templates made available by the CNCF.

    As Kubernetes moves into the enterprise, Parks said IT organizations will need a management framework that can automate the provisioning of application stacks on any combination of legacy virtual machines, Kubernetes clusters and bare-metal servers. Rather than be required to acquire and master separate tools for each platform, Morpheus 4.0 provides a management platform that allows a single DevOps team to manage multiple platforms more easily, he said. As an enterprisewide orchestration and automation platform, Morpheus is designed from the ground up to eliminate the need for DevOps teams to create complex playbooks by providing out-of-the-box integration with wide a variety of IT platforms, Parks added, noting Morpheus 4.0 also now includes Morpheus Jobs, a tool through which jobs can be scheduled or run ad-hoc using Bash, PowerShell, HTTP, Ansible, Chef, Puppet, Groovy, Python, jRuby or JavaScript.

    The number of organizations attempting to unify the management of multiple platforms is expected to increase significantly in the months and years ahead as the number of cloud platforms being employed increases. The challenge those organizations will face involves not only what tools to employ to achieve that goal, but also defining the DevOps processes capable of spanning a hybrid cloud computing environment.

    — Mike Vizard

  • How Serverless Is Impacting the IT Landscape

    How Serverless Is Impacting the IT Landscape

    Although most users will never realize it, with every digital data entry and exchange servers are consuming substantial quantities of energy to file, store and sustain that data’s availability.

    While the average consumer or office worker doesn’t consider the economic or environmental impact they have, IT and C-Suite teams are awakening to the problem and the awareness among energy concerns, legislators and thought leaders is growing. From the expanding troves of transactional data for AI to each video streamed on a smartphone or to a social media platform, hyperconnected companies are hungry to collect, understand, feed and leverage data on our digital habits. In today’s infrastructure models, data centers continuously burn through processing power to be ever-ready to those workloads—even when demand falls during regular off-peak periods.

    That’s one of the two real pushes behind the shift from legacy to new serverless infrastructures: waste, both environmental and economic.

    The world is waking up to the realization that the digital economy is consuming disproportionate levels of energy, putting new pressures on their organizations, their region’s energy infrastructures and, ultimately, on the planet.

    A recent report from Climate Change News predicts billions of internet-connected devices could produce 3.5% of global emissions within 10 years and the communications industry could use 20% of all the world’s electricity by 2025. In fact, data from statistics portal Statista notes the energy consumption of Facebook usage alone amounted to about 2.46TW hours in 2017, compared to 532GW hours in 2011.

    In the U.S. alone, data centers consume an astounding 90 billion kWh of electricity per year, the approximate annual output of 34 (500MW) coal-burning power plants. The data center consumption costs are baked in—organizations pay for always-on computing power to meet peak need regardless of how demand may fluctuate.

    The Promise and Potential of Serverless

    Cutting Energy Consumption: Serverless compute technology such as Amazon’s AWS Lambda or Microsoft’s Azure Functions are native cloud architectures designed to decrease consumption and increase agility and innovation.

    It provides a more efficient function-as-a-service (FaaS) consumption model that enables organizations to pay for what they use, rather than constant peak demand charges.

    Some of the economic impacts of serverless are obvious: Organizations that host their own servers have reconciled themselves to paying for those servers running at full power while sitting idle for much of the time. It’s like keeping your car constantly running, regardless of whether you’re going anywhere.

    In contrast, serverless not only promises far greater energy efficiency from the macro-infrastructure perspective, it also is event-driven. Organizations pay by the computing power consumed, so their costs reflect their actual server usage rather than paying for always-on capacity.

    The Shift Is On, From Managing Infrastructures to Solving Problems

    Reduced energy consumption and cost efficiencies are important for organizations and the planet. Two other major promises serverless offers are the ability to let organizations focus on creating applications and services without chaining them to infrastructure and innovation opportunities.

    Organizations shift the focus of their IT resources away from infrastructure maintenance—the provisioning, patching, operating system maintenance, managing runtimes and capacity planning overhead—to solving business problems. This means the focus of the organization’s IT resources can shift from managing infrastructure maintenance burdens to doing what IT was always meant to do: solve actual business problems.

    But there’s another aspect to serverless that’s even more exciting.

    Unlocking ‘Vendor Lock’ and Unleashing Innovation

    Every great technology breakthrough inevitably tears through old barriers and accelerates innovation. Serverless is no different.

    Furnace is a good example. It’s a new open source, serverless, streaming data processing platform for building big data solutions that are cloud platform and language-agnostic.

    It supports the use of applications that run natively in AWS Lambda, Microsoft Azure and Google Cloud, passporting data between platforms. Using coding languages including JavaScript, Node, Python and Golang, a growing community of developers are creating constructs to connect cloud-based applications.

    Some of the most urgently needed application construct types we’re likely to see in the near term will be for extracting and anonymizing old proprietary data for GDPR compliance, and for honeypot data collection and manipulation, with Elasticsearch and Redshift. Other application foundational on-ramps are in development.

    According to Danny Waite, CTO for the Furnace Ignite organization, the Serverless Furnace source platform was architected to allow deployment and data traversal into and across various cloud, on-premises and hybrid environments, putting the underlying efficiencies of serverless to work on practical applications.

    The application development platform is optimized to ingest massive volumes of data from different sources and in various formats. The Furnace open source community is soliciting feedback and community developers are working on various projects, with plans for constructs to harness and tap into the massive stores of now-untouched IoT data, among other sources.

    Greener, Cleaner, Streamlined Computing

    Serverless is a driver for ecologically greener, operationally cleaner and innovation-driving new computing. Its reduced data-center energy consumption, pay-per-use event-driven model, openness to innovation and seemingly unique ability to help align historical data with new regulatory requirements are all arguments for a shift in thinking and embrace of serverless. The improved economics are another compelling reason, though likely not a primary one for data-driven organizations.

    Serverless communities such as Furnace Ignite are emerging with tools and techniques for adoption. The Furnace application development platform has been architected in a way that allows it to be deployed into various infrastructures, such as cloud, on-premises or within hybrid environments, with the ability to ingest huge volumes of data from different sources, in various formats, so developers can take that data and make it useable. The whole process can be done with speed and agility and removes all the nuances normally associated with working with streaming data.

    Serverless platforms such as Furnace will continue to be developed to drive DevOps and meet the needs of the opensource community.

    — John Blamire

  • Networking: The DevOps Community Deserves Better

    Networking: The DevOps Community Deserves Better

    Developers of cloud-native applications are at the heart of a process of radical transformation shaking up the business world. Using DevOps and SRE methodologies, modern development teams are bringing a level of agility to the game that is all about freeing enterprises from the shackles of the old, pre-cloud days and letting them take advantage of new opportunities at light speed.

    But the developer community has a problem. The process of developing and delivering cloud-native applications in a DevOps paradigm demands the right connectivity to back it up, and traditional networks aren’t doing the job. Cloud-native developers need cloud-native networking—network solutions that work in the same frictionless and agile way they do—solutions that put the application first and replace traditional manual network configuration with connectivity-as-code.

    To play their part, developers need application-friendly connectivity that is designed for applications composed of microservices and APIs which span many edges, clouds and service meshes. A new software only, cloud-native approach to connectivity is required to address this and other challenges such as security, performance and operational support at scale.

    There are four things developers shouldn’t take for granted in a network solution: agility, security, simplicity and performance.

    Agility

    What application developers need is a cloud-native, agile, on-demand alternative to traditional networking—something that delivers the speed to market that they need, and safeguards their profitability. With a model such as application-specific networking in network-as-a-service models, application development teams can create on-demand connectivity across edge, cloud and service mesh environments to support their apps wherever their apps travel.

    Security

    App developers require zero-trust software defined perimeter security that meets and exceeds even the most stringent compliance standards, and can be controlled as code by their DevOps tools and applications.

    Simplicity

    New networking approaches that puts the application in contol can abstract the developer and DevOps teams from the complexity of differences between underlying networks, clouds or service meshes.

    Cost-Effective Performance

    Application-controlled network-as-a-service models can deliver operational cost reduction over traditional MPLS and VPN solutions, while boosting throughput and performance compared with legacy alternatives.

    Conclusion

    Developers deserve better networking. It’s time for them to say goodbye to the old way of doing things and move on from restrictive legacy solutions with their lack of scalability, absence of agility, poor security and unpredictable overheads.

    — Galeal Zino

  • AWS Advances DevOps Agenda at Summit Event

    AWS Advances DevOps Agenda at Summit Event

    Amazon Web Services (AWS) has added services to its cloud platform designed to automate the creation of virtual private clouds (VPCs) and made available additional tools to build applications and integrate external data.

    Speaking at the AWS Summit event, CTO Werner Vogels said these latest services are part of an ongoing effort to automate DevOps processes to the point at which developers will need to write only the code for business logic that runs on top of the AWS public cloud.

    One of the latest tools the company is making available in pursuit of that goal is AWS Cloud Development Kit (CDK), a software development framework for defining cloud infrastructure in code as constructs and provisioning it through AWS CloudFormation. AWS CDK currently supports TypeScript, JavaScript and Python with support for C#/.NET and Java available in preview. That capability will eliminate the need to write low-level code using a different tool just to spin up a VPC on AWS, Vogels said.

    AWS CDK also allows organizations to design and compose their own custom components for managing infrastructure alongside their application code.

    The cloud services provider also announced AWS EventBridge, a programmable event bus for integrating data on AWS with data residing in software-as-a-service (SaaS) applications on any platform based on a serverless computing framework, and the general availability of AWS Toolkit for Visual Studio Code, a plug-in for the Microsoft integrated development environment (IDE) that makes it easier to build, debug and deploy code on AWS.

    Finally, the company announced that Amazon CloudWatch Container Insights is now available in preview. This offering provides access to automated dashboards summarizing the performance and health of their Amazon Elastic Container Service (ECS) and Fargate clusters by tasks. Those offerings come on the heels of AWS Fluent Bit, a tool for container logging being made generally available earlier this week.

    Vogels stressed that the way applications are built is now fundamentally different in the age of the cloud. Developers are making greater use of containers and serverless computing frameworks. The challenge with containers is that in the absence of a cloud service provider to manage the environment, the complexity of the underlying middleware and infrastructure conspires to reduce the amount of time developers spend on writing actual application code, he said.

    To address that issue, AWS is investing more in container and Kubernetes services as well as in on-demand serverless computing services such as AWS EventBridge that don’t require organizations to pay for idle processes, Vogels explained.

    In general, Vogels said AWS continues to advocate for the elimination of separate IT operations and cybersecurity teams in favor of a more unified approach leveraging automated services provided by AWS that ensure, for example, the entire continuous integration/continuous deployment (CI/CD) platform is secure. However, while the number of organizations embracing best DevOps and DevSecOps processes continues to increase steadily, it’s much less clear how many of them will standardize those processes on a single cloud platform at a time when reliance on multiple clouds also continues to increase steadily.

    — Mike Vizard

  • Using Automation to Control Cloud Costs

    Using Automation to Control Cloud Costs

    By building in cost control automation from the very beginning, you can keep your cloud costs low while encouraging innovation.

    Infrastructure automation has become vital for every modern sys admin and operations team. Applications and systems are evolving from single-host mainframes to distributed microservices architectures. This automation has gone from basic operating system installation and setup to full-blown multistep deployments of production code from a single developer’s commit. By automating these mundane processes and eliminating the element of human error, production systems are much more stabile than ever before.

    But why stop at automating deployments? There are other elements that need to be automated, too. One of the main ones is cost control.

    Continually rolling out new infrastructure without ever taking a step back to analyze the cost often leads to the panic-driven cloud-bill-based phone calls from your finance department. Instead, applying automation to your cloud costs can help you to save money, so you never have that unpleasant surprise of a major bill.

    Scaling Up Without Ever Spinning Down

    Developers and operations teams often use infrastructure automation early in application development and deployment processes to get servers and databases deployed and functioning. Modern automation tools aren’t just powerful, but they’re also quick to deploy and fit into your current workflow. This is fantastic, but the problem is the automation effort can taper off once the environments are running—too often, users and teams move on to the next project before figuring out a way to keep costs from getting out of control. Then it’s too late, and users simply accept that money needs to be dumped into the deployment pipeline to keep everything on task.

    Easy-to-use automation is the key to spinning these environments up efficiently. It also can be key for keeping the costs of these environments low. Sure, you may need to keep the production systems scaled up for maximum application performance and customer satisfaction, but what about the test lab, sandbox environment, dev systems, UAT servers, QA deployments, staging hosts and other pre-production workloads? Having giant environments with system sizes that match production can be useful for some testing, but leaving it all running can be easily doubling your cloud costs. This is true for each environment you have, including for elements that are only used for a fraction of the time.

    As your infrastructure automation toolkit grows and evolves, there are a few things you should start building into all of your applications and deployments. These include:

    As this list grows, there’s one more thing you need: continuous cost control.

    By building in cost control automation from the very beginning, you can keep your cloud costs low while maintaining the flexibility required to keep up the pace of innovation. Without this, your costs are destined to rise faster than you intended, which will then cause headaches (and endless meetings) in the future. It may not be coming out of your bank account directly, but saving money at an enterprise organization is everyone’s job. Automating this is the key.

    — Jay Chapel

  • Making Your Cloud Work For You

    Making Your Cloud Work For You

    Does your cloud work for you, or do you work for your cloud? Given the enormous dependency and costs associated with cloud computing, that is a question more and more DevOps teams are asking these days. After more than a decade of pressure from higher-ups to move workloads to the public cloud, DevOps teams are now facing the reality that there is such a thing as too much cloud.

    Don’t take that the wrong way. I’m not here to tell you the cloud is inherently bad or we should return to the days when all our critical workloads ran on bare-metal servers housed in a closet in the back of the office. Public cloud services offer a number of critical benefits and DevOps teams should take advantage of them.

    However, to use the cloud responsibly, it’s crucial to control for two risks. The first is cloud computing costs, which easily can get out of hand if not managed properly. The second is a rigid dependency on public cloud services that undercuts agility and makes it more difficult to deploy applications at scale—which is exactly the opposite of what the cloud is supposed to do.

    In this article, we’ll take a look at what causes each of these risks and how DevOps teams can respond to ensure their cloud strategy actually delivers value.

    Risk 1: Cloud Computing Cost

    You’ve probably heard a lot of talk about how the cloud saves money. If you use the cloud effectively, that is true. However, because of the complexity of cloud computing cost structures and the difficulty of comparing cloud computing costs to on-premises costs, it’s easy to end up with a cloud hangover after paying a much higher cloud computing bill than you bargained for.

    There are several distinct challenges at play in predicting and understanding the true costs of your cloud. Let’s take a look at each one.

    Never-Ending Cloud Computing Costs

    When you move workloads to the cloud, your costs vary month by month and are spread out over time. At first, moving to the cloud feels like a great money-saver because it frees you from having to make large, upfront purchases of on-premises hardware. However, just as leasing a car ultimately costs more in the long run for most people than owning, paying monthly for cloud services hosted on someone else’s infrastructure adds up. If you ignore this fact, you can end up failing to appreciate the true cost of your cloud computing bill over the long term.

    Unpredictable Cloud Costs

    Another fundamental challenge of cloud computing cost compared to on-premises is that, in the cloud, costs structures are opaque and unpredictable. Public cloud vendors change the prices of services without notice. The same service might cost more in one cloud region than another, while some services have multiple fees attached. For example, if you store data in the public cloud, you pay not just a per-gigabyte cost to store it but also fees whenever you move the data. This adds up to tremendous difficulty in predicting your true cloud computing bill.

    On-premises costs are not entirely straightforward to predict either, of course. There are some fluctuating expenses, such as the cost of electricity. However, the lion’s share of on-premises computing costs is the hardware itself, which is a very simple and tangible expense. It’s also a one-time expenditure that you can amortize over the life of your servers. Once you have purchased a server, you don’t have to worry that its effective cost will change month to month, as you would with a virtual server in the public cloud.

    Overlooked Workloads

    In the cloud, it’s trivially easy to spin up a new workload. It’s also easy to leave a workload running after you no longer need it—and public cloud vendors don’t go out of their way to notify you when you have resources that are activated but sitting idle. You can’t blame them; that would be like a restaurant telling you you’re ordering too much food or a builder telling you your house is bigger than you need.

    If you don’t carefully manage your cloud workloads, they add up to extraneous and unnecessary costs.

    To be sure, you can have unnecessary workloads running in an on-premises environment, too. But the difference is there is no substantial cost increase on-premises that accompanies each extraneous workload. You’ve already paid for the servers and you don’t get a bill for every service you have running on your own infrastructure.

    Risk 2: Lack of Cloud Agility

    Beyond unnecessary costs or inefficient cost structures, relying too heavily on the public cloud also undercuts the agility of DevOps teams.

    When you run a service or workload in the public cloud, moving it to different infrastructure can be challenging. Not only is it usually difficult to migrate from one cloud to another, but also doing so entails adapting to a new cost structure and possibly paying more for the same set of services.

    There is an irony here: Conventional wisdom suggests that one of the main reasons to migrate to the cloud is that the cloud is inherently more scalable and agile than on-premises infrastructure. That may be true in some cases, but when you factor in the cost and the difficulty of migration from one cloud to another, the cloud quickly starts to look less agile and scalable.

    On-premises infrastructure doesn’t always scale painlessly either, of course. I don’t dispute that. But the cloud doesn’t always live up to the hype when it comes to scalability and agility. On-premises and cloud-based infrastructures both have limitations in this regard.

    Cutting the Cord: Making the Cloud Work For You

    Now that we’ve identified the inherent (and underappreciated) cost and agility challenges of cloud computing, let’s consider solutions.

    Optimize Cloud Computing Costs

    Cost optimization is something you should always do on any infrastructure, and the cloud is no exception.

    There are many guides out there on cloud cost optimization. Some vendors also offer tools designed to monitor your cloud workloads and identify underused resources or help you right-size cloud service instances. These are all good ways to help reduce your cloud-computing bill.

    Be Cloud-Agnostic

    Another useful strategy is to architect your cloud workloads in a way that makes them as cloud-agnostic as possible. Instead of deeply integrating with a particular cloud vendor’s services, rely on third-party tooling whenever you can.

    For example, if you run containerized apps in the cloud, run your containers in standard virtual server instances and use a third-party registry instead of using the container registry and managed container service of one cloud vendor. This will require a bit more work on your end, but it will give you the freedom to move your workload to another cloud easily. It also enables cost-efficient scalability, because you are not beholden to the cost structures tied to the vendor’s managed container service. Rather, you are using only virtual server instances (and perhaps some storage to go along with them), which have much more flexible pricing on public clouds.

    Don’t Be Afraid of On-Prem

    My final recommendation, and my most important one, is to embrace on-premises infrastructure.

    Again, I say this not because I want to move backwards and return to a world where everything runs on-premises. I’m not anti-cloud.

    However, from a cost and agility perspective, the public cloud is not the best fit for every type of workload. Workloads that have very convoluted cost structures in the public cloud—or that would be difficult to run in a public cloud without sacrificing a great deal of mobility and scalability—are often a better fit for on-premises environments.

    You may be thinking that embracing on-premises means sacrificing all of the advantages of the cloud or having to forgo cloud-native workloads. Fortunately, that’s not the case. There are software vendors that offer the services of a public cloud, but on your own enterprise infrastructure using the public cloud APIs.

    Thus, you can obtain the cost and agility benefits of on-premises infrastructure (not to mention the security advantages) while still running cloud-native applications. In fact, you don’t even need to overhaul your CI/CD pipeline; you can simply deliver your cloud-native apps onto on-premises infrastructure that runs services designed to be compatible with those of the public cloud, even though they are hosted on your own servers.

    Conclusion

    Don’t move workloads to the cloud just because it seems like the thing to do or because someone told you it’s necessarily better. Some workloads work better in the cloud while others are best hosted on-premises. An all-in cloud strategy is not typically the most cost-efficient or agile architecture you can adopt.

    — Ariel Maislos