devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • An Overview of Cloud Migration and Open Source

    An Overview of Cloud Migration and Open Source

    Most businesses are moving toward making their business processes more user-friendly, through digitization. This shift of business modernization comes with a heavy price for them in terms of money and in terms of time. It is going to take time and a great amount of investment in new innovative technologies.

    Cloud computing is the biggest trend in digital transformation due to its ability to make business applications and infrastructure easily accessible. In the roadmap toward cloud migration, businesses are looking to save capital investment or expenses (CAPEX) and operational expenses (OPEX). 

    Open source technologies come to rescue for such businesses. Be those who are present at public cloud platforms such as AWS, Azure or Google Cloud, or private data centers. The role and emergence of open source technologies simplified the equation of overall expenditure for all enterprises and organizations of any industry domains. Year by year, more open source projects are coming up and solve major challenges which businesses are facing. Companies such as Red Hat and communities like Linux Foundation have a major role in promoting open source projects at the heart of digital transformation.

    Why Open Source at Cloud?

    • The main reason to adopt open source technologies in the process of cloud migration can be avoiding vendor lock-in in the future. Most public cloud vendors have a similar portfolio of open source supports in their offerings. As open-source projects are not owned by one company and its overall framework is common to all of its consumers, any updates to its core files have an impact on all projects. And businesses can simply move their application environment from one cloud to another without worrying about backend environment that is powered by open-source projects. There can be a seamless integration of applications and services developed or deployed by different businesses and vendors.
    • Open source adoption for cloud will help in interoperability with other enterprise solutions that can be located in different data centers. Though, other data centers should be equipped with the same open source projects. This interoperability enables the reuse of software stacks, libraries and components. Such interoperability can help deploy multi-cloud environment for businesses.

    The Cloud-Native Approach in Cloud

    Application containerization has been adopted by many solutions providers and vendors in the last few years and has become significantly popular. This containerization surge has triggered the use of cloud-native applications. Most of the popular cloud-native projects are hosted in Linux Foundation’s CNCF (Cloud Native Foundation) community which nurtures the development of various open source projects. Some of the popular projects are Kubernetes, Prometheus, Envoy, Helm, rkt, Linkerd, Etcd, Jaeger, etc.

    The cloud-native approach involves the utilization of tools for handling containers, micro-services, service mesh, DevOps and continuous integration (CI) and continuous deployment (CD). Cloud-native tools for CI/CD can be Check, Ansible, puppet, etc., and service mesh can be Istio, Linkerd, etc.

    Most of the enterprises tend to involve open source projects from various umbrella’s to build the Cloud migration strategy. Moving to cloud-native management of application can be a prominent requirement for many enterprises.   

    Open Source Cloud Migration Tools

    There are open source tools and frameworks that help with cloud data migration. These tools require modification in terms of coding to make the migration process that suits your infrastructure. To make coding customizations in these tools you might need investment for skilled resources.

    The above projects help enterprises to move data. Bluethroat is an open source project which can be used for migration of overall infrastructure from data center to data center, data center to the cloud, cloud to data center and cloud to cloud. Currently it is powered with limited features and used specifically for AWS. It offers the following features:

    • Migration of infrastructure to AWS.
    • Agentless.
    • Environment discovery.
    • Automatic network creation and server deployment.
    • Linux server migration.

    Conclusion

    Cloud migration has its own challenges in terms of uptime, security and data loss. Most public clouds are evolved to handle data as well as application workload migrations. There are many benefits to open source projects, as discussed in this article. The main advantages of migrating open source frameworks to the cloud are cutting back on expenses and avoiding bottlenecks.

    — Sagar Nangare

  • Practical Approaches to Long-Term Cloud-Native Security

    Practical Approaches to Long-Term Cloud-Native Security

    There is no shortage of advice out there about how to secure modern, cloud-native workloads. By now, most developers and IT engineers who work with cloud-native deployments have heard all of the mantras about DevSecOps, shift-left security, multi-layer defenses and dynamic baselining (to name just some of the key concepts that are driving IT security conversations these days).

    One thing is to talk about security best practices and another is to design a cloud strategy that makes it not only possible but also easy to implement them. Even more challenging is planning a strategy that facilitates security best practices over the long term.

    Keep reading for tips on meeting these challenges and devising a long-term security strategy.

    Security Is a Long Game

    It’s easy to think of security as something you have to do in real time. After all, threats and attacks usually happen suddenly, and reacting to them quickly is key to preventing serious damage.

    If your security strategy centers on finding and remediating threats as they appear, you end up stuck in what is essentially a break/fix mode. You’re constantly reacting, rather than being proactive.

    A much more effective security strategy is one that minimizes the threats you face in the first place. That type of strategy requires long-term planning.

    Sure, you will always need to be prepared to detect some threats that you didn’t anticipate, and react quickly in the event a breach occurs. No security plan is perfect, and the unexpected will sometimes still happen. But by focusing as much as possible on long-term security solutions that stop most threats from materializing, you end up with a much safer and more reliable security posture.

    Building a Long-Term Security Strategy

    What does it actually take to implement a security strategy that protects you over the long term? It all boils down to four elements: data, infrastructure, processes and culture.

    Data

    For many organizations, data stored in the cloud is the workload that poses the greatest risk. It’s the reason why there is a seemingly never-ending stream of headlines about major security breaches that involve the theft of sensitive data stored in the cloud.

    Therefore, mitigating threats to data in the cloud is a critical requirement for long-term security. Some best practices in this regard include:

    • Assess your data: Data security starts with knowing what is in your data, and how sensitive the data is. Data cataloging can help with this process, but so can tools such as Amazon Macie, which helps identify personally identifiable information with cloud-based data.
    • Access control: Access control frameworks are another crucial line of defense against cloud-based data breaches. Just remember that simply enabling IAM is not enough; you must also audit IAM policies to avoid misconfigurations that could lead to a breach (which was the lesson learned by Capital One, among others).

    Infrastructure

    These days, we tend to treat infrastructure–meaning the cloud-based and/or on-premise data centers that host workloads–as a relatively generic and interchangeable part of the solution stack. But while it is true that, generally speaking, no one cloud or data center is inherently more secure than another, the way you design your infrastructure plays a key role in your ability to secure modern workloads over the long term.

    Best practices on the infrastructure front, for long-term security include:

    • Immutable infrastructure: Embrace infrastructure platforms, such as ECS or EKS, that make it easy to deploy and update applications in an immutable way. Immutable building-blocks may not work for all use cases, but where possible, they reduce the number of variables and handoffs you have to contend with in order to deploy or update an application (and the more variables and handoffs, the greater the chance of an oversight that will create a security vulnerability).
    • Access control: While IAM frameworks can help prevent some types of unauthorized access, you can also increase the security of your infrastructure using Access Control Lists. A best practice is to adopt a whitelisting approach that blocks all traffic by default, and allows only explicitly trusted hosts.
    • Avoiding bloat: Cloud-native infrastructure makes it easy to spin up virtual machines, databases or other infrastructure components that you don’t truly need, and keep them running. Doing so increases your attack surface. For that reason, identifying and shutting down unused infrastructure is critical for ensuring long-term security. It also helps cut cloud costs, but that is another topic.
    • Parity: In order for developers, ITOps and security teams to be able to communicate and coordinate effectively, they should all be working with the same types of infrastructure environments. Collaboration becomes much more difficult if, for example, you use an on-premise data center for development, then deploy production workloads to the cloud. Avoid this by striving to create parity across your infrastructure whenever possible.

    Processes

    Processes are the second key ingredient in creating a long-term security plan for cloud-native workloads. Obviously, the processes you use will reflect, in part, your particular workloads and tools. But no matter your situation, your processes should be designed with the following security goals in mind:

    • Consistency: Your IT organization may consist of different teams, each with different responsibilities and agendas. Nonetheless, to the extent possible, all teams should follow the same procedures when developing, testing, staging and deploying applications. Doing so reduces the chances of variables or oversights that can undermine security. You can help achieve this consistency by creating and enforcing IT governance procedures across the organization.
    • Shift-left: Processes are the part of your IT operation where shift-left security can have the greatest effect. Shift-left security means making security a priority from the start of the application delivery pipeline. Importantly, however (and this is a point that some organizations overlook), doing shift-left security correctly also means bolstering security operations at later stages of the pipeline, too. Don’t just shift security left and call it a day; aim to make security a primary consideration at all stages of your delivery chain.

    Culture

    Culture is something that can be difficult to formalize; indeed, if you try to stuff cultural values down your employees’ throats, you risk compromising the whole point of having an organic culture in place. Instead, you want to encourage your team members to naturally embrace values that promote a culture of security. Strategies that can help achieve that include:

    • Bug bounties: Incentivize your team to look for and address security issues by hosting bug bounties for your organization’s workloads. For this purpose, “bug” should be defined broadly to include not just security bugs within code, but any kind of configuration issue in your infrastructure, tools or applications that could lead to security vulnerabilities. That way, your bug bounties can include not just developers, but all members of the IT organization.
    • Encourage shared ownership: A culture in which each engineer owns a specific application, infrastructure or process is one that limits transparency and opportunities to address security risks. Strive instead to promote shared ownership of IT assets so each team member knows his or her work may be reviewed by others, which helps to encourage best practices and reduce security issues. In essence, these are part of the values that DevOps and DevSecOps prioritize.

    Conclusion

    By designing infrastructure, processes and cultural practices that promote security, you put your organization in a position to optimize security over the long term. Planning ahead for security is the only way to escape the break/fix cycle of responding to vulnerabilities as they are discovered, which leaves you always treading water and never pushing the needle. You won’t be able to prevent all security issues, but you can greatly reduce the number that crop up by baking security into your infrastructure, processes and culture.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • AWS Applies Machine Learning to Optimize Cloud Deployments

    AWS Applies Machine Learning to Optimize Cloud Deployments

    Amazon Web Services (AWS) this week at its re:Invent 2019 conference unfurled two tools based on machine learning algorithms to optimize cloud application deployments.

    Amazon CodeGuru is a service available as a preview, through which the cloud service provider will inspect application code using machine learning algorithms to profile the code and then identify bottlenecks and what part of that code is the most expensive to run on the AWS cloud.

    AWS Compute Optimizer, meanwhile, identifies optimal Amazon EC2 instance types, including those that are a part of Auto Scaling groups, for specific types of workloads. It analyzes the configuration and resource utilization of a workload, including historical metrics, to identify dozens of characteristics to recommend optimal AWS compute resources. AWS Compute Optimizer is accessed via the AWS Management Console. Rather than rely on humans to optimize cloud platforms, AWS is making a case for reducing the time and effort required to determine which of dozens of instance types will deliver the highest performance at the lowest cost possible.

    Amazon CloudGuru can pull code from either GitHub or CodeCommit repositories, with support for other repositories planned. It requires developers to insert agent software developed by AWS into their code. Once a pull request is made, Amazon CodeGuru will automatically start evaluating the code using trained artificial intelligence (AI) models that AWS developed using data gathered from thousands of different open source software projects by AWS and its parent company.

    Once the analysis is completed, Amazon CodeGuru will generate a “flame graph” showing, for example, latency issues and CPU utilization rates alongside human-readable recommendations to surface specific issues and recommended remediations that include example code and links to relevant documentation for any line of code. Amazon CodeGuru can observe application runtimes and profile application code every five minutes.

    AWS CEO Andy Jassy told conference attendees that Amazon is already employing Amazon CodeGuru across 80,000 applications, which has resulted in increases in infrastructure utilization rates that have reached 325% in some cases.

    While machine learning algorithms have a clear role to play in terms of enabling DevOps teams to build and deploy more efficient code, it’s not clear to what degree DevOps teams will want to give AWS that level of access to what are often highly proprietary applications. Many DevOps teams may prefer to employ machine learning algorithms within the context of a continuous integration/continuous deployment (CI/CD) environment to drive code to multiple cloud computing platforms. Whatever the approach pursued, it’s clear machine learning algorithms are about to play a much larger role in DevOps. In fact, Jassy this week made it clear AWS will be applying machine learning algorithms broadly to enhance everything from enterprise search to identifying potential fraud.

    What is less clear is how best DevOps practices will need to evolve to account for machine learning algorithms. Many of the processes that make up a DevOps toolchain are increasingly being automated. That doesn’t eliminate the need for the toolchain, but it will sharply reduce the amount of time and effort required to build and optimally deploy applications.

    — Mike Vizard

  • Logz.io Adds Monitoring Service Based on ELK and Grafana

    Logz.io Adds Monitoring Service Based on ELK and Grafana

    Logz.io today at the AWS re:Invent 2019 conference launched Cloud Observability Platform, a monitoring and security cloud service based on ELK—open source Elasticsearch, a search engine; Logstash, a data processing pipeline; and Kibana, a set of visualization tools—and Grafana, an analytics and monitoring platform.

    Company CEO Tomer Levy said it’s become apparent that developers have a strong preference for open source tools for managing cloud-native applications. As such, the adoption of ELK has increased substantially. With the increasing maturity of Grafana, it’s also becoming clear that organizations want to meld the open source analytics and monitoring tool with previous investments in ELK tools, he said.

    However, not many IT organizations have a lot of ELK and Grafana expertise. To fill that gap, Logz.io is launching a managed cloud service based on Logz.io Log Management, an instance of ELK that the company has enhanced with machine learning algorithms and data analytics capabilities to enable DevOps teams to discover and resolve issues faster.

    That core platform is being extended via Logz.io Infrastructure Monitoring, a beta release of a monitoring platform based on Grafana, and a security information and event management (SIEM) platform dubbed Cloud SIEM, based on an ELK stack that includes built-in threat detection tools.

    In addition, Levy said Logz.io plans to add support for Jaeger, an open source distributed tracing tool being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    Levy said it’s apparent to all that observability is a core tenet of DevOps, which he said is why there are already a half-million developers making use of ELK software. The challenge organizations are finding is that monitoring modern IT environments based on cloud-native applications is cumbersome and time-consuming. Logz.io is addressing that issue by providing an enterprise-grade instance of an open source monitoring platform that comes with hundreds of built-in connectors, which enables DevOps teams to employ a monitoring platform without having to be worried about becoming locked in to a specific vendor because they can switch over to open source code anytime they like, Levy noted.

    Developers tend to favor open source tools because they don’t have to wait on purchasing approval to employ them. However, enterprise IT organizations tend to favor platforms that are supported by a commercial vendor. Logz.io is trying to address that issue by providing support for an open source platform that will make enterprise IT organizations comfortable enough to give up relying on a proprietary monitoring platform. Thus far, Logz.io has more than 700 customers, which the company expects to expand now that it has an instance of its platform that can be consumed as a cloud service.

    It’s too early to say to what degree an open source platform might usurp proprietary platforms in the enterprise. Change tends to come slowly to enterprise IT organizations. However, as organizations embrace next-generation applications based on microservices and containers, enterprise IT organizations are clearly evaluating their monitoring platform options going forward.

    — Mike Vizard

  • HPE Adds Control Plane to Greenlake Managed Service

    HPE Adds Control Plane to Greenlake Managed Service

    Hewlett-Packard Enterprise (HPE) announced today it has added a cloud platform to its managed Greenlake service, through which DevOps teams will be able to manage deployments of applications alongside HPE.

    Scott Yow, vice president and general manager for GreenLake Hybrid Cloud Software at HPE, said HPE Greenlake Central provides a control plane that makes it possible for DevOps teams to write, release and deploy code quickly, without having to manage the IT infrastructure directly in an on-premises IT environment.

    Instead, DevOps teams will have access to an array of tools and services from HPE and partners through a marketplace to create a workbench through which they can design and create applications using best DevOps practices, said Yow. For example, HPE will make it possible for DevOps teams to leverage Terraform tools from HashiCorp to enable DevOps teams to manage infrastructure as code.

    Announced at the HPE Discover More Munich event, GreenLake Central is in trial with general availability scheduled for the end of the first quarter of 2020. The goal is to make it possible for DevOps teams to access distributed IT infrastructure in an on-premises IT environment that is managed in much the same way cloud platforms are accessed, said Yow. HPE will provide the expertise required to consistently manage underlying IT infrastructure, while DevOps teams employ Greenlake Central to manage the application environment.

    The Greenlake service also surfaces a dashboard through which IT teams can leverage more than 1,000 controls to meet almost any compliance mandates. Reports generated via that console substantially reduce the time and effort required to audit the IT environment as well.

    HPE is essentially making available a “co-pilot” approach to managing IT infrastructure that enables DevOps teams to focus more of their efforts on managing applications. HPE also published the results of a survey of 1,000 IT decision-makers that finds 86% of respondents agree that “as-a-service” approaches to managing IT are now inevitable and 75% expect their organization to move toward full adoption of such models in less than five years.

    Today the Greenlake service is designed around a series of virtual machine options spanning offerings from HPE, Nutanix and VMware. However, HPE plans to add support next year for a recently launched HPE Container Platform that can be deployed on top of virtual machines or bare-metal servers. IT organizations also should expect HPE to extend the Greenlake control plane to public clouds to advance hybrid cloud computing to ensure IT organizations maintain ownership of the control plane to manage those environments, Yow said.

    Greenlake is at the forefront of an HPE initiative to transition all its offerings into a set of managed services. That “as-a-service” approach has already gained traction with more than 740 customers worldwide, including 160 new customer wins this year. By 2022, HPE has promised to make its entire portfolio available as a service.

    HPE is not the only provider of IT infrastructure leveraging managed services to provide DevOps teams with access to a more flexible IT environment. Historically, these types of managed services were provided by third-party IT services providers. In the age of the cloud, HPE is betting more organizations will prefer to have their IT infrastructure managed by the vendor that built it in the first place. Of course, as part of that transition, HPE is making a case for standardizing on its infrastructure.

    It’s too early to say how the marriage of DevOps and managed services will play out in on-premises IT environments. The one thing that is clear, however, is that DevOps teams increasingly need to manage the IT infrastructure on which their applications are deployed only if they really feel the need to do so.

    — Mike Vizard

  • Why AWS Cost Optimization Is About More than Saving Money

    Why AWS Cost Optimization Is About More than Saving Money

    Why is it important to track and monitor cloud costs? The obvious answer is it helps you save money—and everyone wants to save money.

    Yet, cost plays a much larger role in your cloud journey. If you think about cost only in terms of how much you are paying and what you are getting in return, then you’re missing much of the value that careful cloud cost control can provide.

    Let’s take a look at all of the reasons why monitoring and optimizing costs is critical for a successful AWS strategy.

    What Is Cost Optimization?

    In AWS and other clouds, cost optimization is the art and science of identifying and addressing inefficiencies in the way you are using resources.

    Those inefficiencies come in many forms. They could be an EC2 instance that offers more resources than you need for a given workload, which could therefore be replaced by a different, less costly instance.

    They could be a result of using one type of application architecture, like workloads running directly on virtual machines, when another, such as serverless or containers, would deliver the same performance for less overall cost.

    They could be caused by failing to take advantage of the best opportunities available for hosting a given workload. For example, you might be using S3 Standard for storage when S3 Glacier would meet your needs just as well, at a lower cost.

    By identifying these sorts of problems, you can take steps to spend less while maintaining the same level of performance for your cloud workloads. A basic best practice is to use tools such as AWS Trusted Advisor to help ensure that your infrastructure is set up in a cost-efficient way from the start.

    Cost Optimization Insights

    These tools only go so far, and they are not the be-all, end-all of cost optimization. They are designed simply to help choose the right type of configuration for a given workload. However, cost monitoring as a whole goes further, and delivers several other important types of insight into your AWS workloads and strategy.

    Rogue Infrastructure

    By its nature, rogue infrastructure—meaning use of infrastructure for purposes not officially authorized by your organization—is hard to detect. If it wasn’t, it wouldn’t be very good at being rogue.

    If you monitor cloud costs carefully, however, rogue infrastructure will have a hard time hiding. If employees spin up a virtual server in the cloud for personal use, or create storage buckets for organizational data that is not supposed to exist in the cloud, you are likely to discover it when you perform cost optimization operations designed to help identify workloads that should not be running.

    Having a strong IT governance policy in place that requires all cloud-based resources to be tagged is another way to help prevent the creation of rogue infrastructure, and to make unauthorized resources easy to detect. When possible, tagging should be automated to ensure the fastest and most consistent results.

    Security Risks

    Although cost optimization is certainly not the only tool you should use to help identify security issues in your cloud workloads, it provides some useful insight that other tools might lack.

    For example, if you notice that your bills for a certain application or service have increased due to heavier usage without a corresponding increase in legitimate requests, it could be a sign of brute-force attacks or other unauthorized access attempts.

    Neglected Projects

    When was the last time you evaluated each of your applications to ensure it was running as efficiently and securely as possible?

    If you don’t know because you don’t regularly do this, cost optimization can help ensure that you do recognize workloads that could stand to be reconfigured. If you discover that you are paying more than you expect for a given workload, or that one workload’s costs are rising more quickly than those of others without a clear reason, it’s probably time to take a look at that workload and assess whether it should be scaled up or down, migrated to a different type of service, or otherwise adjusted to operate more efficiently.

    Operational Inefficiencies

    Finally, cost optimization can help you identify inefficiencies in the way your organization is run. That is because fees charged by AWS that you could have avoided but didn’t might reflect larger inefficiencies within the organization.

    For instance, consider AWS data storage costs. If your AWS cost analysis shows you are paying early-deletion fees for data stored in S3 Glacier, you should determine why that is happening. It could be simply because you should be using a different storage class, but it could also be because employees are deleting data sooner than intended.

    Conclusion

    Saving money by being cost-efficient should always be one of your goals. But running your overall business in an efficient, transparent manner is another. AWS cost optimization can help you achieve all of this.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Accenture Cloud Simulation Platform Advances DevOps

    Accenture Cloud Simulation Platform Advances DevOps

    Accenture has launched a cloud simulation service through which DevOps teams can better determine which workloads will run best on different cloud computing environments.

    Kishore Durg, growth and strategy lead for cloud at Accenture Technology Services, said myNAV is a cloud service created by Accenture that leverages machine learning algorithms and other forms of artificial intelligence (AI) to leverage a knowledge base Accenture developed during its decade-plus working on cloud projects. DevOps teams can leverage that expertise without requiring Accenture personnel onsite to account for deployment variables such as technology infrastructure, types of application workloads, data, operational models and even business outcomes before committing to a specific cloud computing platform, he said.

    DevOps teams can also employ myNAV to engage in canary testing of application workloads, Durg added.

    DevOps teams employing myNAV are guided through a three-step process that starts with scanning and assessing the existing infrastructure, application and data landscape to recommend the most appropriate cloud architecture. An AI engine developed by Accenture then accesses a knowledge base curated by Accenture to come up with a recommended enterprise architecture. Finally, simulation and testing tools are applied to make sure the IT environment will scale as required.

    At the end of the process the DevOps team is presented with a bill of materials that resembles the bill of materials that might be presented when building a house, said Durg.

    Despite commodity pricing models, not all cloud computing platforms are created equal. Various attributes of application workloads lend themselves better to different attributes of cloud computing platforms. It’s not uncommon for IT organizations to find themselves rolling back applications from a cloud platform after encountering performance issues or discovering that cost of running a specific type of application on a cloud exceeded their available budget.

    Durg said 3-D visualization tools make it a lot easier to determine which cloud platform to employ and derive the maximum value from that investment by ensuring the cloud environment chosen is optimized for that application workload. Accenture research suggests that as many as two-thirds of organizations are not getting the maximum value from their cloud investments, he noted, and most of those issues stem from the cloud platform being poorly configured, added Durg.

    Whether by accident or deliberate, most IT organizations are employing multiple clouds to build and deploy applications, but their cloud platform selection process is often haphazard. Developers often default to the cloud platform that is easiest for them to access, which could create cloud platform lock-in. Cloud simulation platforms make it easier for the entire IT team to better appreciate the trade-offs in selecting one cloud platform over another.

    Of course, most IT teams would like to unify the management of multiple clouds under a single console through which they can more easily play one service provider off against another using a hybrid cloud computing model. Until that day arrives, however, most IT organizations will find it advantageous to know as much as possible about any cloud platform before making a decision they may come to regret.

    — Mike Vizard

  • Headless Commerce: Why E-Commerce Is Losing Its Head

    Headless Commerce: Why E-Commerce Is Losing Its Head

    How headless commerce is changing the way commerce platforms are designed and services are offered

    Within the last 15 years we’ve seen commerce technology evolve at a breakneck pace. In the early nineties, online shopping was limited to simplistic webstores built around self-contained, all-in-one software solutions. And with consumer engagement restricted to web browser access via at-home desktop computers, many assumed e-commerce would never find its way to mainstream acceptance. Fast forward to the present: E-commerce is ascendant and traditional retail has been toppled from its throne. Immersive online shopping environments establish a sense of belonging, transforming casual shoppers into lifelong brand loyalists. Seamless e-commerce experiences are tailored to specific individuals, complimented by lightning-fast fulfillment, next-day delivery and 24/7 customer service.

    As a result of these changes, self-contained software solutions have surrendered to agile commerce platform architectures offering a more open, granular approach digital customer experience management. In particular, “headless” commerce has drawn significant hype for its unique approach to commerce architecture, involving separation of a commerce platform’s front-end customer experience from back-end business processes. But just how much of a game-changer is headless and who stands to benefit most from it as this approach becomes more widespread?

    Separate the Front and Back

    Historically, the front-end and the back-end of commerce platforms were intrinsically tied at the hip. Headless commerce allows a brand to separate the front-end experience from the back-end business processes such as management of the merchant’s catalog, product pricing, promotional offers and day-to-day management activities. This separation enables marketers to embrace new channels and new customer touchpoints by removing any dependencies of new front-end releases having to be developed, deployed and managed together with the back end. It gives the front-end UX team complete creative control over what the experience should be and can be based on the needs of the brand. This is opposed to being prescribed a commerce experience that has to follow specific processes and workflows. When done effectively, headless opens up and gives the front-end customer experience designers freedom to think outside the box and build experiences that aren’t constrained in any way.

    5G is Bottom Line

    With the evolution of 5G networks and the ability to put low-cost transmitters into any device or product, the number of things in the workplace or products we own that are connected to the internet has increased significantly. A few years ago, only a few items things such as your laptop and your phone were connected to Wi-Fi. Now it’s a list of 30 or 40 things in your house that are permanently connected to your Wi-Fi. Eventually, Wi-Fi will become obsolete and everything will connect over 5G, leading to the possibility of having hundreds of connected devices just inside your home. All of those connected devices will ultimately fuel business models that can only benefit from a headless approach.

    Many of the products we buy today are becoming more connected. By being connected to the internet, businesses can provide a value-add service, whether that’s a paid subscription or something freely provided by the brand. For example, if you buy a NEST home security camera from Best Buy, you pay a one-time fee of $400. However, once you buy it there’s also a subscription for recording and storing all the video footage. This scenario is ideal for companies looking to profit from a headless commerce business model, as the product needs to continually call home to determine if it has entitlements, if the customer is up to date on their paid subscriptions and so forth.

    Headless in the Future Means Preparation in the Present

    While headless is the future, everyone isn’t fully ready. It requires budget and teams capable of using headless commerce technologies. Generally, it’s a fit for larger, well-funded enterprise organizations that have significant in-house technical capabilities, architects and their own development teams versed in building their own custom, front-end experiences. For smaller businesses, a lot of it is about future-proofing their platform technology to prepare for a solution that supports headless in the future.

    With much-misunderstood hype around the topic, headless is still a growing term and concept within the industry. It’s going to take a push from those who are creating demand for headless such as a chief architect or CTO. If you don’t have a strong IT organization that really understands the vision of how your company is going to be more agile with a headless approach, then it’s kind of a non-starter.

    Traditional commerce is becoming a thing of the past. Headless is the future and it’s going to take everything we have to pave the way.

    — Peter Sheldon

  • Optimizing AWS Performance Over the Long Term

    Optimizing AWS Performance Over the Long Term

    Ask most folks how to optimize performance on AWS, and they’ll talk about things such as autoscaling and rightsizing.

    Those tools are certainly part of an effective AWS performance optimization strategy. On their own, however, they are not enough to guarantee performance and reliability over the long haul.

    That’s because tools and processes such as autoscaling and rightsizing only help you optimize the performance of applications that are running currently, or are about to be deployed. They do little to ensure that performance remains optimal—especially as cloud services, cost structures and architectures evolve.

    With that challenge in mind, let’s discuss how to get the most out of AWS performance over the long term.

    What is AWS Performance?

    Before delving into long-term AWS performance strategies, let’s make clear what we mean by performance. A high-performing application is one that:

    • Meets or exceeds user expectations regarding responsiveness and speed.
    • Meets or exceeds SLA requirements for availability.
    • Is able to scale seamlessly as performance requirements change.
    • Does all of the above in a cost-efficient manner.

    These aspects of a high-performing AWS application are important to emphasize because they reflect a holistic approach to performance. Sometimes performance is defined narrowly, in terms of application responsiveness and/or availability. Those are part of the performance equation, but in order to maximize performance over the long term, you need to think about other dimensions of performance, like the role played by scalability and cloud spend.

    Long-Term AWS Performance Considerations

    To optimize AWS performance over the long term, you must take a variety of factors into consideration.

    Handling AWS Service Changes and Upgrades

    AWS is constantly evolving. A performance strategy that works well today may not be as effective tomorrow if AWS introduces a new service or changes the features of an existing service.

    The challenge here lies not just in updating your app and your cloud configuration as AWS changes how a particular service works. It also requires constantly evaluating whether the service you are using is the best fit for your application.

    For example, think back about five years to when AWS Lambda (AWS’s serverless computing service) appeared. At the time, if you were running your apps inside virtual servers, you might have been able to improve overall performance by moving some of the workloads to serverless functions—not because anything in your virtual servers had become less efficient, but because better efficiency opportunities opened up with the addition of a new AWS service.

    Thus, being constantly aware of the various services in AWS and the opportunities they offer is key to optimizing long-term performance.

    Plan for Changing Cost Structures

    AWS not only changes its menu of service offerings frequently, it also updates pricing. Since cost optimization is one key component of performance optimization, you must ensure that your cloud workloads are running in the most cost-efficient way even as cost structures change.

    Staying aware of new cloud services (such as lower-cost S3 storage tiers) when they appear is one way to do this. But you also need visibility into the tremendously complex world of AWS pricing in all of its region-specific details.

    Plan Long-Term for OSS Dependencies

    Open-source software is something else that is constantly changing. If you rely on open source code to help run your AWS applications, you need to stay on top of changes in the projects you depend on.

    If you are using the same version of an open-source application or module that you built into your application when you first deployed it, you may be missing out on performance optimization opportunities that have arisen since then.

    Here again, constant awareness of and visibility into the complex open-source ecosystem is essential for ensuring that you are not missing out on optimization opportunities.

    Application-Specific Performance Monitoring

    Every application is a special snowflake and you need to keep that in mind when it comes to the way you track and optimize application performance.

    The metrics or KPIs that work for optimizing the performance of one app may not be ideal for another. The pre-deployment testing routines you use for applications might vary, too.

    So, make sure to tailor your monitoring strategy to your applications. Doing so is the only way to ensure you have the greatest, most relevant level of visibility into application performance over the long term.

    Backup and Disaster Recovery

    No matter how well your AWS workloads perform, sooner or later something will go wrong and they will fail. Whether the failure leads to a critical availability disruption or a mere hiccup hinges in large part on whether you have a backup and disaster recovery plan in place beforehand.

    For AWS apps, an effective backup and recovery plan entails more than just backing up data to storage buckets and downloading it to rebuild servers. It should also take advantage of opportunities like the ability to create image-level backups of virtual servers and restore them automatically to EC2 if disaster strikes.

    And of course, as AWS changes, you’ll need to keep your backup and recovery strategy in sync.

    Changing SLA Requirements

    Last but not least, keep your SLAs in mind. The SLAs you have to support today could change in the future—and by extension, so will the levels of availability and responsiveness that your users expect.

    For this reason, make sure your AWS performance strategy is capable not only of meeting the SLAs you currently have in place, but also adapting and scaling as SLA requirements become more rigid.

    Conclusion

    Although we tend to think of performance within the context of the present, it’s really a long-tail game. Sure, you can autoscale your workloads or use rightsizing tools to help choose the best type of EC2 instance for right now. But truly maximizing performance requires you to think longer-term and be prepared to react with agility as new performance challenges and opportunities arise.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Why Integrated Infrastructure Is the Key to IT Success

    Why Integrated Infrastructure Is the Key to IT Success

    At first glance, your IT infrastructure might seem like your house’s basement. It supports everything, but you don’t pay much attention to it or spend much time or energy trying to make it beautiful. Instead, you treat it as a generic component and lavish your attention on other parts of your IT landscape (or your house, as it were).

    But the fact is that infrastructure is not so simple and generic. The way you design your infrastructure, as well as your ability to integrate it with the ever-changing set of tools that you need to keep workloads running efficiently, plays a critical role in defining overall business success.

    To prove this point and encourage you to give your infrastructure some much-needed love, keep reading for an overview of why well-integrated infrastructure is so crucial, and why implementing an infrastructure that integrates seamlessly with the rest of your solution stack is an important best practice.

    What Is Integrated Infrastructure?

    By integrated infrastructure, we mean infrastructure that seamlessly connects with the entire ecosystem of tools you use to deploy and manage applications.

    To put that into context, consider some examples of how infrastructure interfaces with tools:

    • Your CI/CD pipeline needs to be able to integrate effectively with the infrastructure that hosts CI servers, testing tools and build tools.
    • Release automation software must be able to deploy seamlessly to the infrastructure that will host live applications.
    • Monitoring and performance optimization tools need to work easily with whichever infrastructure hosts your workloads, since monitoring the underlying infrastructure is one critical component of application monitoring.
    • Security and access-control tools must be able to apply security policies and restrictions to host infrastructure to help keep applications secure.

    The list could go on, but you get the idea: an integrated infrastructure is one that can easily interface with all of the tools you use to create, deploy, manage and secure the workloads you host on that infrastructure.

    Agnostic Infrastructure Versus Integrated Infrastructure

    You may be thinking, “It’s 2019, and most infrastructure is agnostic. My tools don’t care which cloud I use to host my workloads.”

    You’d be right that most modern, cloud-native infrastructures are designed to be agnostic toward the tools that are used with it. Although there are certainly exceptions, the majority of infrastructure solutions available today—whether they are from a public cloud vendor, or local infrastructures built using standard operating systems and hypervisors—can be configured to work with pretty much any mainstream tool you throw at them.

    But agnostic infrastructure is not the same as integrated infrastructure. An integrated infrastructure is one in which the connections between your tools and your infrastructure are not only possible to create, but happen seamlessly.

    This difference is easiest to see if you compare public cloud vendors’ native tools with tools from third-party vendors that work with those clouds, but don’t always integrate seamlessly with them. For example, pretty much every modern APM tool can be configured to work with AWS. But setting them up takes time, and there is no guarantee they will always be compatible.

    In contrast, there is CloudWatch, AWS’s native monitoring tool. It falls far short of being a complete APM solution, but it is seamlessly integrated with any AWS infrastructure. You don’t need to configure or install anything to use it, and it scales automatically with your AWS footprint.

    Achieving Infrastructure Integration

    My point here is not that you need to choose between a feature-limited native toolset and a third-party one that offers more features but does not integrate as well. Instead, you should strive to build an infrastructure and a toolset that offers the best of both worlds: rich features and tight integration.

    The best way to do that is to take a toolset-first approach. By that, I mean identifying which tools you need and designing your infrastructure around them. That is preferable to the strategy that most organizations use by default, which is to choose an infrastructure (usually a cloud provider) and then figure out how to reconcile their toolset with it. Not only does this approach limit your choice and inflate your costs (because you may end up having to use native tools from your cloud vendor that are less cost-effective than third-party alternatives), but it also makes integration between your tools and your infrastructure more difficult.

    Before you go and migrate all of your workloads to one public cloud or another, identify the various tools you depend on and evaluate how well each of them integrates with the clouds (or other infrastructure solutions) available to you. You may find that you should choose an infrastructure strategy built on multi-cloud or hybrid cloud to achieve better integration with your toolsets. This type of approach will make infrastructure architecture more complex, but it enables better infrastructure integration, which delivers more value in the long run.

    Integrate for Today and the Future

    Keep in mind, too, the tools you use today can, and probably will, change in the future. Thus, you want to ensure that your strategy enables tight infrastructure integration over the long term.

    Here again, a multi-cloud or hybrid cloud strategy is probably the best approach for maximizing flexibility and integrability, although you’ll need to assess your specific needs by looking at your tools first, and then plan an infrastructure strategy that will accommodate them as they evolve and grow.

    Conclusion

    The bottom line is this: Although infrastructure might seem like a mundane and largely interchangeable part of your IT landscape, the extent to which it is well integrated with your tools can make or break the overall effectiveness of your IT strategy. Don’t choose infrastructure first and then shoehorn your tools to fit it. Instead, design your infrastructure architecture around the tools you need, and make sure it can continue to accommodate them as your strategy evolves.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi