devopsy.kinsta.cloud

Tag: AWS

  • AWS Unfurls Bevy of Automation Tools to Streamline DevOps

    AWS Unfurls Bevy of Automation Tools to Streamline DevOps

    At the AWS re:Invent conference, Amazon Web Services (AWS) added a bevy of tools to its portfolio intended to accelerate the pace of application development while simultaneously simplifying DevOps processes.

    AWS development tools unveiled this week include AWS Amplify Studio, a visual development environment that allows developers to create web application user interfaces (UIs) with minimal coding.

    Ken Exner, head of product for developer tools at AWS, said as an extension of an existing AWS Amplify Studio tool, this latest addition allows developers to customize application UIs at a higher level of abstraction using a library of components while enabling them to drop down to a lower level of coding to customize their application further whenever required. After the UI is designed, AWS Amplify Studio automatically generates the associated JavaScript or TypeScript code for the developer.

    In general, AWS is committed to improving developer productivity by providing, for example, automated reasoning tools that automate processes without locking devs into a layer of abstraction that, ultimately, may create a wall that blocks them from meeting customization requirements, he said.

    Other developer tools launched by AWS this week include updates to Amazon CodeGuru Reviewer that adds a secrets detector that uses machine learning algorithms to identify hardcoded secrets that can be secured using AWS Secrets Manager; a revamped Amazon Inspector vulnerability management tool that provides automated assessment scans, automated resource discovery, support for container-based workloads, improved risk scoring, integration with Amazon EventBridge and AWS Security Hub and the removal of the stand-alone Amazon Inspector scanning agent.

    AWS also revealed it has eliminated the need to manually pull images from the Amazon Elastic Container Registry (ECR) repositories by adding automated synchronization capabilities that keep private and public registries consistent with each other.

    In terms of IT operations tools, AWS added a managed database service to its Amazon Relational Database Service portfolio that allows IT teams to customize the underlying database and operating system using an RDS Custom option, a new table class for Amazon DynamoDB designed to reduce storage costs for infrequently accessed data and a service for RDS, dubbed Amazon DevOps Guru, that extends existing machine learning capabilities to automatically detect and diagnose performance bottlenecks and operational database issues.

    Jeff Carter, vice president for relational databases at AWS, said that as databases are increasingly managed by DevOps teams rather than traditional database administrators (DBAs), the cloud service provider is moving to reduce friction by automating as many manual tasks as possible. That’s critical at a time when IT teams are deploying a much wider range of purpose-built databases that are optimized for different classes of applications, he added. The overall goal is to rely more on automation to reduce friction across the IT environment, said Carter.

    Overall, there are two classes of AWS customers: The first are development teams that are increasingly relying on managed services provided by AWS to automate a wide range of DevOps processes. The second tend to be enterprise IT organizations that prefer to manage cloud services themselves.

    Mitch Ashley, a principal for Techstrong Research, an arm of the parent company of devopsy.kinsta.cloud, noted that, in many cases, enterprise IT teams are managing DevOps workflows that span multiple clouds. As such, they tend to prefer tools and platforms that can be applied to both multiple clouds and on-premises IT environments. The more those organizations rely on managed services provided by a cloud service provider the more difficult it becomes to consistently manage DevOps workflows across multiple IT environments.

    It’s too early to say just how much IT organizations will rely on managed services going forward. However, at a time when more organizations are using more IT platforms than ever, it’s clear the DevOps management challenge increases with each new platform introduced into the IT environment.

  • AWS re:Invent Roundup: Private 5G | Graviton3 ARM Chips | DevOps Guru++

    AWS re:Invent Roundup: Private 5G | Graviton3 ARM Chips | DevOps Guru++

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Three things that caught my eye from Amazon Web Services’ re:Invent 2021 conference: Private 5G, Graviton3 chips, and something called DevOps Guru for RDS (yes, really).

    Private NRaaS vs. Wi-Fi

    First up this week: AWS Private 5G is a new turnkey service, offering local private cellular data infrastructure, for places where Wi-Fi just doesn’t cut it. Despite the name, it offers a 4G/LTE fallback to 5G/NR. Because it’s AWS, the hardware is free—you just pay for usage.

    Analysis: Combine with an Outpost for a sharper edge

    Wi-Fi is unreliable and low powered. 5G over the 3.5 GHz “citizens’ band” seems like a great alternative (just don’t tell the lunatic fringe of the anti-5G brigade).

    And, of course, AWS makes it easy to buy—Amazon ships you all the private radio gubbins for “free” and just bills you based on capacity and usage. It’s automatically configured and remotely maintained. You just take your internet connection and plug it in.

    Aisha Malik: Amazon launches preview of new AWS Private 5G managed service

    “AWS Private 5G” … is a new service that aims to make it easy to deploy and manage your own private network. … AWS CEO Adam Selipsky said that with AWS Private 5G, you can set up and scale a private mobile network in days instead of months.
    …
    There are no upfront fees or per-device costs: … Customers pay only for the network capacity and throughput they request. [It] scales capacity on-demand.
    …
    AWS Private 5G is available in preview in the United States.


    And this is better than Wi-Fi how, exactly? Ballu counts the ways:

    Industrial area coverage: Where you need 50 Wi-Fi radio units, you can provide service with 3–4 p4G/p5G radios.
    …
    Hazardous areas: Where you can’t provide the networking at all the corners or areas, one p5G radio blast area (esp with beam technology) can.
    …
    Packet loss: Less packet loss compared to Wi-Fi (believe me, it’s a big deal in the Industrial world)
    …
    Compatibility: What’s a negative for 5G modems (not many devices are available), is positive to some extent. Once investment is made with 5G modems, the devices can be on the road too.


    Unsurprisingly, Brian Roemmele feels vindicated:

    Precisely as I wrote about in 2017 to great ridicule from an analyst at a famous VC firm: Amazon is becoming a phone company.
    …
    From the Sidewalk Network to the Kuiper satellite system to local 5G. The network is no longer just “dumb pipes.”

    Graviton3: AWS ARM SoC is PDQ

    Graviton3 is the latest version of Amazon’s ARM server chip. It looks like it’s based on a 5nm process implementing the latest ARMv9 ISA. AWS is making the usual claims about it being much faster than the previous generation, but it also has new security features.

    Analysis: Cool chips

    AWS is deadly serious about low-power, high-performance compute. Amazon is just one licensee that would be distressed to have Nvidia owning Arm.

    As I said last week—and the week before that—ARM chips are an increasing fixture in the datacenter, especially ones that value “performance per Watt.” Other IaaS providers might bleat about how they’re reducing the energy used to cool their data centers, but surely it’s a better plan to start with less waste heat.

    Maria Deutscher: AWS debuts new compute-intensive and AI instances powered by custom chips

    AWS’ new Amazon EC2 C7g instances target compute-intensive workloads such as analytics tools and scientific modeling software. The C7g series is based on the AWS Graviton3 chip, the third iteration of the cloud giant’s internally-designed processor.
    …
    Companies that plan to use C7g instances for machine learning workloads can expect an up to threefold performance jump in AI performance. The speed jump is partly the result of the processor’s support for bfloat16, a specialized data format [that] enables applications to process floating point numbers faster and using less memory than FP32, the data format historically used for the task.
    …
    For cryptographic tasks, Graviton3 delivers as much as double the performance of the Graviton2. … The chip introduces a feature called pointer authentication to reduce the risk of cyberattacks.


    Tim Anderson has been sifting through the re:Invent announcements:

    Top of the list perhaps is Graviton3, the next generation of AWS’s homemade [ARM] server processors. These chips will be used in new C7g instances previewed offering DDR5 memory (50 percent more bandwidth than DDR4) and up to 25 per cent better compute performance compared to instances powered by Graviton2.
    …
    Adam Selipsky gave his first Re:Invent keynote as AWS CEO. [He] said Graviton uses “up to 60 per cent less energy.” … Graviton matters because it is among those leading a charge to get more [ARM] microprocessors into data center and cloud infrastructure, and because if it’s more energy and cost efficient to operate, it’s critical to Amazon’s bottom line, sorry, today’s environmental concerns.


    And is that pointer-authentication feature useful? Yes, very, says spijdar:

    Very useful. … If the performance is good, this is a nice extra layer that makes return-oriented programming more difficult. Combined with NX bits, it really raises the difficulty in developing/using many types of exploits (it’s not impossible to bypass … but there’s no perfect security).

    DevOps Guru Adds RDS Support

    DevOps Guru for RDS is the latest upgrade for AWS’s oddly-named smart monitoring features.

    Analysis: Silly name; useful tool

    Laplace and Gauss were right: Your DevOps team aren’t all rockstars. “Average” ops staff are in the majority. So extending AWS’s monitoring automation to your database instances should be a positive step.

    But that branding: Can anyone take it seriously?

    Stephanie Condon: AWS brings more automation to database management

    The new Amazon DevOps Guru for RDS automatically can find and fix database issues … helping developers using Aurora detect, diagnose and resolve database performance issues. [It] can help remediate a range of issues, such as over-utilization of host resources, database bottlenecks, or misbehavior of SQL queries.
    …
    Last year, AWS introduced DevOps Guru, a service that uses machine learning to automatically detect and alert customers of application issues. … Amazon DevOps Guru for RDS builds on that
    …
    Users can view [issues] in the DevOps Guru console or via notifications from Amazon EventBridge or Amazon Simple Notification Service (SNS).


    Sounds interesting, says u/random_dent:

    I thought the DevOps Guru for RDS sounded interesting. You need to enable performance metrics first, which have their own charges, but it still looks not too expensive, plus three months free-tier, so we may try it out.

    We’ve had some odd issues with RDS performance that are too inconsistent to lock down. It would be interesting to see if this could give us some insight.


    But that name! Here’s Thomas LaRock—@SQLRockstar:

    I’m old enough to remember when DevOps Guru for RDS was just called “database performance monitoring.”


    And @shmick is young enough to say it like this:

    such a cringe name

    The Moral of the Story: Misfortune tests the sincerity of friends


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Andrew Svk (via Unsplash)

  • Fugue Marries Compliance-as-Code Tool to AWS Well-Architected Framework

    Fugue Marries Compliance-as-Code Tool to AWS Well-Architected Framework

    Fugue has infused the best practices defined by Amazon Web Services (AWS) within its software-as-a-service (SaaS) offering for provisioning infrastructure using its infrastructure-as-code (IaC) platform.

    Fugue CEO Josh Stella said that IT teams can now evaluate templates for provisioning AWS infrastructure that were created using AWS CloudFormation or Terraform tools to ensure they comply with the AWS Well-Architected Framework.

    The AWS Well-Architected Framework spans five pillars that AWS has defined for designing and operating reliable, secure, efficient and cost-effective systems in the cloud. AWS has defined a set of best practices for each pillar and rewards organizations for following those by making available additional cloud credits. The goal is to improve overall cloud security by providing guidance that ultimately reduces the number of misconfigurations so that cybercriminals can’t discover and exploit them.

    The Fugue platform complements that effort because it is based on Open Policy Agent (OPA), a general-purpose engine for managing compliance-as-code that is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). Fugue extended OPA by creating Regula, an open source tool that evaluates IaC files for potential security and compliance violations. Fugue then created a SaaS platform that makes extensive use of the AWS Lambda serverless computing platform to make it easier to enforce compliance policies.

    Those policies include turnkey coverage for specifications such as SOC 2, NIST 800-53, GDPR, PCI, HIPAA, ISO 27001, CSA CCM, CIS Controls, CIS Docker and CIS Foundations Benchmarks for AWS, Microsoft Azure, Google Cloud and Kubernetes.

    Stella said Fugue has now incorporated the technical aspects of the AWS Well-Architected Framework. However, it’s still up to each IT team to navigate the cultural aspects of the shared responsibility model of compliance and security that cloud service providers like AWS follow.

    Unfortunately, developers that employ IaC tools to provision cloud infrastructure often make some faulty assumptions about the level of security maintained by the cloud service provider. The result is often a raft of security and compliance issues that arise mainly because most developers don’t have a lot of domain knowledge expertise in either area.

    It’s not clear how many organizations have adopted the AWS Well-Architected Framework, but as various tools make it easier to implement these best practices defined by AWS the more secure and efficient cloud computing environments should become. In fact, in many cases, those tools are being embedded within a larger set of DevSecOps best practices that are being implemented across multiple clouds.

    Stella said he doubted there will ever be any standardization when it comes to security and compliance frameworks that could be applied to multiple clouds; however, it’s clear that cloud service providers are at least making available frameworks that borrow concepts from one another.

    Regardless of the approach, the overall state of cloud security and compliance will continue to improve as more guardrails are automatically implemented. The issue then becomes not only finding a way to ensure that cloud infrastructure is secure when deployed and also determining how much of the infrastructure being relied on today is less secure than it should be.

  • WhiteSource Report Finds NPM Vulnerabilities Fixed Fast

    WhiteSource Report Finds NPM Vulnerabilities Fixed Fast

    WhiteSource today published a report that found most of the vulnerabilities that affect node package managers (NPMs), widely employed to deploy JavaScript applications, are addressed long before they are assigned a Common Vulnerabilities and Exposure (CVE) in the National Vulnerability Database (NVD).

    The report, based on an analysis of the vulnerabilities that WhiteSource tracks in its own vulnerability database and revealed at the AWS re:Invent conference, found more than 90% of vulnerabilities in NPM packages are fixed before the vulnerability is published in the NVD.

    Susan St. Clair, director of product management for WhiteSource, said that fact suggests that, overall, the open source community is staying on top of vulnerabilities as they are disclosed rather than waiting for them to be assigned a CVE number.

    The WhiteSource report comes on the heels of a breach of UA-parser.js, a widely employed NPM based on a JavaScript library that detects browser, engine, OS, CPU and device type/model from User-Agent data. Unknown malicious actors found a way to inject malware into the NPM that modified the library. That vulnerability has since been remediated.

    In fact, the WhiteSource report noted 83% of the CVEs assigned to the most widely used versions of vulnerable NPMs could be remediated before the publication of the CVE.

    In the wake of a series of high-profile breaches of software supply chains, there is a lot more focus on how open source software is actually secured. Commercial software products have a distribution list that they typically notify of a security patch. Open source updates, on the other hand, need to be tracked by developers that use that software. The level of attention individual developers might pay to any number of open source updates can vary widely.

    Many developers are also hesitant to immediately update their applications because they are not sure what impact that additional code may have on their application, said St. Clair. For example, their application may have dependencies that are no longer backward compatible with the updated code, she noted.

    Developers also need to determine the degree to which that vulnerability may affect their applications because they often don’t use every component of an open source library, so the fix being offered may not be required.

    Open source project maintainers often depend on their community to help uncover vulnerabilities and create the fixes as quickly as possible. When a vulnerability is detected in an open source library, the more common practice is to report it to the NVD even after the fix for that issue has been made available.

    In general, St. Clair noted the most important thing for the open source community to remember is to remain proactive when it comes to tracking vulnerabilities and then implementing DevSecOps best practices. The one thing that is certain is that a wide range of malicious actors also are tracking those vulnerabilities closely. It’s not uncommon to see a wave of exploits being created once a vulnerability is disclosed via the NVD.

    The challenge, of course, is that the more open source software that is employed, the more difficult it becomes for individual developers to stay on top of every vulnerability in an application portfolio that only continues to grow. On the plus side, vendors have pledged more than $10 million to help better secure open source software. Hopefully, the return on that investment will become apparent sooner than later.

  • AWS BugBust Challenges Developers to Set World Record for Bug Busting at re:Invent 2021

    AWS BugBust Challenges Developers to Set World Record for Bug Busting at re:Invent 2021

    Software bugs are irksome, time-consuming and can be one of the most expensive software development costs for any company on an ongoing basis. Software Testing News cited a study that found the cost of poor software quality in the United States alone was estimated to be $2.8 trillion dollars. Let that sink in. $2.8 trillion dollars. And 18.22% of that cost was technical debt. Pair that with the fact that Watts Humphrey1 estimated in his book, A Discipline for Software Engineering, that, on average, software developers make 100 to 150 errors for every thousand lines of code.

    Suffice it to say that the costs of poor software quality are significant.

    Welcome to the First Annual AWS BugBust re:Invent Challenge

    AWS is making a commitment to help software teams around the world improve software quality with their global AWS BugBust Challenge. The first annual AWS BugBust re:Invent Challenge is right around the corner.

    The challenge, taking place from November 29, 2021 at 10 a.m. PST through December 2, 2021 at 2 p.m. PST, enlists Java and Python developers to collectively fix bugs and eliminate technical debt using Amazon CodeGuru. Within this time frame, registered participants across the globe—participating virtually—and those present onsite at the BugBust Hub at the AWS re:Invent Expo, can compete to fix as many bugs as possible to win prizes, glory and claim the title of the Ultimate AWS BugBuster. For each bug that you fix, you receive points based on the complexity of the bug. The more bugs you fix, the more points you will gain and the higher you will climb up the AWS BugBust Leaderboard. The live leaderboard will track each participant’s progress and showcase the number of bugs fixed and points received.

    Be a Part of Setting a Bug-Busting World Record

    At re:Invent, AWS also is looking to set a Guinness Book of World Records record for the largest code-fixing challenge ever. To date, there are no existing records for an event of this kind. Fix at least one bug to qualify to be part of setting the Guinness record. You can join onsite or online. Be part of the excitement of trying to set a world record while winning prizes and gaining recognition!

    Milestone Prizes

    While developers will go head-to-head to win the title of the Ultimate AWS BugBuster, they will also have the opportunity to win prizes for their milestone achievements. The Grand Prize will be $1,500 in cash. 

    There will be five key milestones that developers will be working towards:

    • First milestone—1 point—AWS BugBuster Fly Swatter
    • Second milestone—50 points—AWS BugBust branded sanitizer (BugSpray)
    • Third milestone—150 points—AWS BugBust glow-in-the-dark Bug Jar
    • Fourth milestone—300 points—AWS BugBust hoodie
    • Fifth milestone—500 points—AWS BugBust branded Echo Dot
    • Grand prize—$1,500 for the top BugBuster

    In addition to the milestone prizes, all developers who have contributed toward setting the record for the world’s largest code-fixing challenge will receive an exclusive AWS certificate. The bugs fixed at this live event will count toward the global total which the AWS BugBusting team will have front and center at the event.

    AWS BugBust Hub

    The BugBust Live Challenge will be hosted in the BugBust Hub. The Hub will provide a fun and relaxing environment for developers to fix bugs and ask questions of the AWS BugBust SWAT team as they get started on the BugBust Live Challenge. Not on-site at AWS re:Invent? No worries—developers can still participate and win prizes virtually, too!

    For more information and to pre-register for the AWS BugBust re:Invent Challenge, please visit the AWS BugBust website.

    1 Known as “the father of software quality,” Watts S. Humphrey is the author of numerous influential books on the software development process and software process improvement. Humphrey is a fellow of the Software Engineering Institute (SEI) at Carnegie Mellon University, where he founded the Software Process program and provided the vision and early leadership for the original capability maturity model (CMM). He also is the creator of the personal software process (PSP) and team software process (TSP). He was awarded the National Medal of Technology―the highest honor given by the president of the United States to America’s leading innovators.

  • Sustainability No Longer Just a Buzzword for Cloud IT

    Sustainability No Longer Just a Buzzword for Cloud IT

    A recent CloudBolt survey on IT sustainability finds that sustainability is no longer just a buzzword — the market is demanding real change, and it appears that environmental concerns finally are influencing large IT investments. For example, 67% say that a cloud provider’s sustainability initiatives are important in deciding whether to do business with them. A significant portion of organizations are even willing to pay a premium to support green initiatives!

    Below, I’ll review the report to find its major takeaways. We’ll see how sustainability is directing real action in cloud IT and briefly compare how the market perceives current green initiatives among three top cloud providers: AWS, GCP and Azure.

    Sustainability Gains Real-World Traction

    In June and July 2021, CloudBolt polled 256 global CxOs and tech leaders on its Pulse platform, and found that 76% of respondents now consider climate change an existential threat. Not only are IT purchasers factoring compute and cost, but a sustainability conscience is now influencing executives to direct sweeping change. In fact, 79% of respondents indicate their IT departments are expected to help their companies achieve specific sustainability initiatives driven by the board of directors of the C-suite.

    Interestingly, other studies found that a sustainability commitment results in tangible business outcomes. For instance, 88% of the research conducted by Oxford University and Arabesque showed that solid environmental, social and governance (ESG) practices result in better operational performance of firms and higher profits. This study also noted that 80% of the time, a company’s stock price is positively influenced by sustainability practices.

    Climate Conscience Guides Cloud Choices

    Most organizations now consider a cloud vendor’s sustainability initiatives when choosing whether to do business with that provider. A full 78% of respondents agree that the public/private cloud choices they make can materially affect the environment for better or worse. New environmental cloud commitments not only attempt to minimize carbon emissions from their data centers but factor in ecological ramifications and aim to erase companies’ historical carbon footprints, as well.

    Cloud consumers also want to contribute to addressing these green initiatives. An impressive 79% of respondents indicate that they will pay a premium to work with vendors who incorporate sustainability into their business. And 41% of companies are willing to pay a premium of 11 % to 15% of their current bills. This shows that sustainability is now a vital factor within the marketplace, and companies are willing to pay the price to increase their own environmental standing.

    Though this commitment is undoubtedly growing, the report did find that operational requirements such as security, cost and agility, still rank significantly higher than sustainability when comparing cloud providers. Though IT professionals recognize climate change as an existential threat, they still have day jobs and must keep operations moving.

    AWS: King of Green Clouds

    Slightly more than half (51%) of respondents agree that the industry-wide green energy commitment is real and growing among all cloud providers. However, when comparing the top three—Amazon Web Services (AWS), Azure and Google, AWS appears to be emerging as an IT sustainability leader; 41% of respondents perceived AWS as doing the most to address green initiatives.

    AWS is on track to power its entire operations with 100% renewable energy by 2025. With their solar plant investment in April 2021, Amazon became the largest corporate buyer of renewable energy in Europe. Around the globe, AWS has invested in a combination of on-site solar, solar farms and wind farms to power their data centers and Whole Foods divisions.

    To their credit, both Microsoft and Google also committed to climate pledges that affect their cloud footprint. Azure supports a similar initiative to reach 100% renewable energy by 2025, in addition to further investments to improve water, waste disposal and surrounding local ecosystems. Google Cloud’s commitment is to operate on carbon-free energy 24 hours a day by 2030, and the company has already achieved 100% renewable every year since 2017.

    Not only does AWS appear to be doing the most to address its environmental impact, it also retains the most market traction as a cloud leader. The majority of respondents (62%) said that AWS is winning the cloud wars while only 31% said Azure and just 7% said GCP.

    Final Thoughts

    It is heartening to see that ESG standards are having a measurable impact on a company’s cloud allegiances. The market now demands real change and is willing to pay the price for more ethical and sustainable cloud hosting.

    But choosing a cloud provider is only one aspect of reducing IT’s impact. As I’ve covered before, there are many ways IT can curb its climate impact. Such actions include optimizing overall infrastructure, shuttering zombie VMs, avoiding over-provisioning resources, increasing performance visibility, refactoring code and other measures. What’s great is that most of these initiatives have the added benefit of reducing cost to the business.

    The CloudBolt Industry Insights Report, The Truth About IT Sustainability: Paying More Green to Get More Green, surveyed 256 IT leaders on their perception of cloud sustainability. For additional insights, you can pick up a copy here.

  • How to Achieve AWS Competency Accreditation

    How to Achieve AWS Competency Accreditation

    For businesses in the early stage of their ventures, proving that they have the expertise and technical know-how when it comes to cloud technology can be difficult. An acceleration toward digitization due to COVID-19 and an increasingly crowded cloud market, dominated by the big players, means that simply shouting about your skills in cloud engineering and DevOps isn’t enough to get noticed.

    But what if you can work alongside these giants? Joining forces with expert brands and entering into endorsement partnerships can propel your business forward by supplementing it with seasoned expertise. Accreditation, if you can achieve it, can give you a stamp of approval and reassure prospects that you have the relevant knowledge to support their digital transformation efforts. Collaborating with industry leaders on skills accreditation programs is a great way to demonstrate your capabilities and provides clear goalposts to work toward when it comes to building and learning.

    So, how do businesses achieve this status and what are the long-term benefits of the process?

    Become an AWS Partner

    Achieving accreditation as an AWS DevOps Competency Partner takes a lot of hard work and investment into building the technical skills required to reach such a high standard–logging and evidencing every action your team takes is no mean feat. From beginning to end, the course takes around six months. The process begins with researching and selecting which specific competency your team is interested in achieving. It’s important to understand which competency your business is most suited to, so doing your homework is key. From there, there’s a lot of work to evidence, certificates to achieve and reviews to undergo. Becoming an accredited AWS partner brings a multitude of benefits to your brand, so it is well worth the investment.

    Top Tips for the Accreditation Process:

    Create detailed accounts of your work: To become a certified DevOps partner, businesses need to evidence four case study examples; two public and two private. As such, it can be useful to bring in a tech writer to consolidated your notes and observations throughout the process. We began, for example, with a technical exploration from the team to understand the best case studies to put forward; our work had to be clearly evidenced with strong examples and the documentation to back it up which took a considerable amount of time to pull together. Maintaining clear and detailed accounts of previous work can prevent any delays. This information is firstly analyzed by AWS to check that it met the specific requirements before being passed on to be examined by a team of external auditors, so every detail counts when it comes to showcasing your work.

    Prepare the marketing team: As part of the process, businesses are required to have certain marketing collateral in place across their website to aid with lead generation. For the DevOps competency certification, we needed to evidence three technical blogs–businesses applying for the certification need to ensure that the content best reflects their expertise in the given competency. Once the accreditation is finalized, the partnership should be displayed on the site. Even if a business is tech-agnostic, demonstrating your skills in a particular type of cloud engineering is highly valuable to your brand and AWS is a respected platform to use.

    Advance technical training in the workplace: Having members of the team qualified in cloud engineering is another requirement for accreditation. For DevOps, we needed eight people on the team to have achieved their associate certifications and four to have achieved professional certifications. To fulfill this requirement and ensure we’re on top of our game when it comes to cloud training, we’ve invested in third-party tools, provided access to LinkedIn Learning programs and we give our people additional time off from client-facing work to prepare for their exams. Building and learning in tandem is the fabric of our culture, and a similar approach would benefit any company looking to achieve certification status.

    The Benefits of AWS Accreditation

    Being able to showcase a close association with a major player such as AWS opens up a number of doors for smaller businesses. Operating within this kind of business ecosystem provides the opportunity to demonstrate a business’ DevOps and technical skills to an enormous global audience which can drive new business conversations and drive quality leads. Confirmation that your business is a trusted partner for a major cloud organization will ensure that prospects have confidence in your capabilities and you’re taken seriously as a technical player in the market. Building confidence within your teams and supporting them in their learning is an investment that will pay huge dividends.

    Working alongside AWS as an accredited DevOps partner gives us a springboard to talk about our work and engage with other players in the market. The accreditation is a fantastic talking point and definitely gets you noticed in the cloud community–plus, you will be taken more seriously as a partner.

    Investment in Cloud Tech is Key for the Future

    As businesses everywhere begin to operate in an increasingly digitized environment, technical skills and cloud expertise are a necessary investment for any business. Working toward coveted industry accreditations while prioritizing long-term skills training is imperative. It’s a competitive, buoyant market for cloud engineers and DevOps at the moment; opportunities are at their fingertips and if they aren’t feeling fulfilled by their current work, they’re likely to look elsewhere. Investment in training and nurturing growth in this way breeds employee engagement and loyalty. For a company to thrive technically, it needs to host a wide range of diverse talent and be able to retain it. Learning opportunities should always be the key focus.

    The shortage of this talent means it’s critical to advance the business’s cloud expertise by pursuing recognition from major global players like AWS. Providing advanced training and certification opportunities for your people will ensure long-term talent retention while making the business a leader in cloud engineering. That’s pivotal for long-term success.

  • Cloud Security Requires Shared Responsibility

    Cloud Security Requires Shared Responsibility

    The Growth of Public Cloud and the Need for Cloud Security

    Since 2006 when Amazon first introduced EC2 — the first public cloud service — cloud has become a major staple of enterprise information technology strategy. Both Infrastructure as a Service (IaaS) and newer cloud services continue to grow robustly. Enter the need for cloud security.

    While providing undeniable benefits to users such as scalability, speed to market, and cost savings, public cloud offerings also created a new dilemma: Just who was responsible for security when the platform was no longer protected on the user’s  premises,  and was in some part controlled by a third-party vendor?

    Cloud security is an issue the industry has had to solve in order to achieve such impressive growth. Since 2014, security services have been a key focus area of cloud providers. This includes protection of the infrastructure itself and tenant boundaries, as well as advanced services protecting the data itself. Without security, no reasonable enterprise would use public cloud in production.

    AWS Approach To Shared Responsibility Model

    As a public cloud pioneer, Amazon Web Services (AWS) was the first provider to introduce the term “shared responsibility model” and its components, starting to think about improving  cloud security to a level sufficient to protect enterprise production workloads.

    According to Amazon:

    ‍“Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.”

    In short, AWS secures the cloud’s physical infrastructure, compute, and network systems  from outside physical access and from digital access and insider threats.  The customer’s responsibility is to protect everything they run in the cloud.

    What Needs To Be Secured in a Cloud Deployment?

    The importance of security in the context of public cloud has led to formation of the Cloud Security Alliance (CSA). CSA has their own interpretation of the shared responsibility model.

    From the CSA’s perspective, the following are the categories of cloud systems that need to be secured:

    Information and Data – Data are the crown jewels of any digital business. From the addresses of paying customers to sensitive financial records and employees’ information ,  protecting data is critical to the success of any online business. Further, many compliance regulations, especially the recent focus on GDPR and CCPA, exert additional pressure to protect personally identifiable information.

    ‍Application Logic, APIs, and Code – The data are interpreted and processed by the application logic and application programming interfaces, or APIs. The code that implements applications can represent a core competitive advantage for the enterprise, but the logic itself and protection of the APIs is extremely important for securing  both the business and its data.

    ‍Users, Authentication, and Access Control – Users — who are both owners of the data and the source of revenue for the online business — , also need protection. From account takeover to identity theft, malicious actors can harm the users. The owner of the service where such attacks take place  is ultimately responsible for providing security.

    ‍Platform and Resource Configuration – This is the only major component of the cloud that is protected by the cloud provider itself. Protection is typically extended to the physical premises, computing resources, including cooling and physical maintenance requirements, network resources, virtualization systems and hypervisors, resource management systems, storage systems and so on.

    As Platforms Evolve, Does Shared Responsibility Change as Well?

    Newer cloud services go beyond providing just infrastructure-as-a-service and may influence how we think about shared responsibility.

    For example, some of the more interesting platform offerings include serverless compute services, a cloud development model that allows developers to build and manage applications without having to worry about server management. These offerings include  AWS Lambda, AI-as-a-service, (such as Google Cloud AI), and hosted blogs like Medium.

    If the application uses one of these advanced services, it changes how the shared responsibility model is applied because the provider is not just responsible for the host, but also for the security of the platform itself.

    While this helps us sort out security responsibilities, we must still consider security of information and data (think hosted WordPress blog); security of intellectual property and code (such as the case with serverless);  and security of the API and application logic (as might be the case with a hosted Kubernetes infrastructure, Amazon Elastic Kubernetes Service or Azure Kubernetes Service). All these data, application logic and code elements should still be secured by the cloud user or enterprise according to the shared responsibility model.

    There are a couple of additional important security considerations for newer platforms. Watch out for cloud lock-in. While running a guest Linux OS makes it extremely easy to migrate  workloads back on premises or to a different cloud, running the logic on a hosted platform makes the migration more difficult: the logic becomes dependent on the provider APIs. Secondly, data flows and compliance becomes a touch more difficult because best practices are not as well established for newer platforms.

    How Traceable Can Help with Cloud Security

    Traceable Defense AI provides application protection that helps fill in the customer’s share of the shared responsibility, especially as data flows, application logic, and APIs are concerned.

    Data flows – Traceable observes the data flows throughout the application running on the platform and identifies sensitive data for compliance purposes.

    API security in pre-production and production – Traceable maps out the application flows, protects applications and APIs from run-time threats, assesses API risks and helps with threat analysis and compensating controls.

    User-centric view – Traceable identifies suspicious activities and anomalies. When suspicious activity is detected on a previously well-behaved account, it’s an indicator of an account compromise. Combined with a rate-limiting functionality, this helps protect legitimate users.

    Traceable is a born-in-the-cloud company that prides itself on helping enterprises adopt cloud-native architectures in production. Understanding the shared responsibility model, selecting the cloud provider that holds up their end of the bargain, and using the right cloud security tools to fulfill the enterprise share of security responsibility is what will make the cloud truly secure.

    To learn more about Traceable you can visit us at https://traceable.ai or view a recorded demo.

  • Multi-Cloud Is Not About Lift and Shift

    Multi-Cloud Is Not About Lift and Shift

    Multi-cloud is often framed from the perspective of “lift and shift.” In other words, an organization takes a computing environment previously running on one cloud and transfers it over to a different service provider. Cloud migration may make sense for cost savings or performance benefits and such a shift may be necessary when migrating on-premises data centers to a public cloud.

    In theory, lift and shift sounds like it would empower cloud consumers with more choice in the marketplace. However, according to John Gentry, CTO of Virtana, lift and shift is quite rare in practice; it may not be the true driver behind multi-cloud strategies. Moving resources between clouds can result in costly egress fees. Plus, culturally-ingrained cloud preferences become challenging to shake. Unique configurations and add-on software-as-a-service (SaaS) make each cloud more nuanced, requiring new skills and procedures with every migration.

    Instead, Gentry advocates for a “fit-for-purpose cloud” strategy. This attitude is less about moving similar workloads between clouds but, instead, pairing particular types of workloads with the appropriate cloud types. According to Gentry, using multiple clouds simultaneously could still help organizations strategically align their digital resources and reduce dependency on a single cloud service provider (CSP). But, the real value of a hybrid multi-cloud setup lies in matching computing environments to different business layers.

    Fit-For-Purpose Cloud

    At first glance, the ability to move between clouds appears to be driving a new multi-cloud economy where cloud strategists can swiftly migrate resources and optimize intercloud utilization. However, when organizations attempt to shift, they usually experience many hidden costs, Gentry warned. These often pop up around data egress. Or, new data storage costs may take a surprising toll, Gentry added. “A lot of companies look at it from a computing perspective and they don’t account for the storage footprint.”

    DevOps in the cloud also introduces new responsibilities and processes that may differ between clouds, continued Gentry. From unique storage operations to managing the life cycle of a virtual machine, each cloud carries unique configuration methods. This makes it more difficult to abandon established procedures in favor of a different computing arrangement.

    Nevertheless, Gentry recognizes that we’re starting to see a maturing effect of the multi-cloud concept, especially among large enterprises. “Companies have a multi-cloud strategy—it’s less about moving between clouds than about picking a cloud that has specific advantages for a given workload,” he said. In a fit-for-purpose cloud approach, different workloads correspond to different layers of the business. For example, an organization may require a local data center or private cloud for high-security data. Certain applications may benefit from a distributed global public cloud, whereas other workloads could reap performance benefits and cost savings from a cloud-adjacent edge model. “These specific areas may not have anything to do with one another other than supporting the overall business,” explained Gentry.

    Matching Cloud Types to Business Units

    So how do we match the workload at hand to the ideal computing arrangement? Gentry identified three emerging cloud types:

    • Private cloud: A private core for particular functions that can’t be replatformed or rearchitected. Business areas such as financial records or patient care hold sensitive data that must be stored properly to meet regulations and SLAs.
    • Public cloud: End customer-facing, where sensitive data is not an issue. Public distributed cloud is ideal for delivering a highly available front end for customer-facing digital experiences.
    • Cloud adjacent/edge: When an environment is kept in a cloud adjacent facility with relatively local geographies. This may sit alongside the public cloud or connect to a front end in a cloud.

    For example, Gentry described how a large health care company uses a hybrid multi-cloud setup to support various business divisions. The organization is keeping traditional patient care workloads exclusively on-premises; due to regulatory reasons, it will never see the inside of a cloud. Yet, they are simultaneously building the next generation of applications in a public cloud, using Google Cloud to scale a clinical trial division. Simultaneously they began using Microsoft Azure for their back office. This scenario highlights one peculiar advantage of late-stage cloud adoption, noted Gentry: “They had the advantage of being able to take a more thoughtful approach.”

    Gentry described another case of an organization performing genomic sequencing. For data-heavy applications like this, where there is a high dependency on input and output, syncing with a public cloud could be extremely costly and introduce latency. For them, the most cost-effective method was to use a cloud-adjacent or edge model alongside a public cloud.

    How to Leverage Fit-For-Purpose Cloud

    One situation that may warrant cloud migration is a complete replatforming, noted Gentry. He described one early cloud adopter that rushed into AWS, only to find it wasn’t cost-effective for their needs. Architects then had to make tough decisions to determine what would be repatriated back to local data centers and what should remain in the cloud. “Their only motive going from cloud to cloud was, ‘We made a bad choice and we want to move.’”

    Clearly, to match cloud use with business requirements, you must choose the appropriate cloud. AWS is widely adopted for elastic computing and offers a wide product catalog. GCP is offering feature innovation and cost reduction to compete and is going after un- and under-penetrated regions. Azure, on the other hand, will offer licensing advantages if you are a Microsoft shop.

    Secondly, to unite IT around a hybrid multi-cloud strategy, you must remove the adversarial state between traditional ops and cloud ops. Classic ops is typically very safety-oriented, using a slow approach with endless tests in pre-production. Traditional ops may produce yearly updates. This is directly opposed to the new cloud ops approach, which emphasizes agility, speed and constant deployment. “They sit in different silos,” Gentry explained.

    To solve this dilemma, companies must share technical skillsets between the three main cloud types. “DevOps must become a continuum for all types,” Gentry said. In addition to cultural change, DevOps tools must evolve to monitor workloads across a hybrid multi-cloud estate. This will require integration to tie together tools and deeper observability.

  • Don’t Look at This! IT’S A SECRET!

    Don’t Look at This! IT’S A SECRET!

    To continue the discussion about secrets after perusing this excellent report by GitGuardian—last time I went a little nuts about the number of secrets exposed in IT folks’ personal repositories. And it is a lot. I mean a lot of secrets. But you know what is scarier than, “A lot of secrets are leaked in personal repositories of people rushing to get this week’s sprint in”? The fact that 30,000 secrets were leaked via corporate public repositories in 2020. That’s thirty thousand.

    This is not some poor DevOps person in a rush to meet deadlines and with no real security support for personal repositories who dropped some secrets into a public personal repository.

    This is a system set up by your organization that should have security awareness, should be getting scanned regularly and that should never be a source of information for hackers. Instead, it is a source of information, perhaps even critical information, that hackers can easily snag. Because there are secrets in this public repository.

    The first step to avoiding this problem is to acknowledge that IT can’t serve every need, and ask business units (BUs) to come forward with any apps they’ve developed behind your back so that (non-invasive) security can be applied to those apps.

    You’ll either get some apps, or people won’t trust you and you won’t get any. In the latter case, truthfully explain about secrets hiding in public repositories and ask them to validate their own. It’s the best you can do if people won’t share what they’ve done, and there are still people out there that think IT involvement is a huge impediment to their software. ::Shrug:: As long as you can get them to check their apps for vulnerabilities, it shouldn’t matter too much. But I’m more concerned about getting the secrets, so I won’t debate the centralized-versus-distributed-app philosophies in this blog beyond saying, For secrets, if you can get them to scan/clean them up, the question of who is managing the app and the process isn’t very important.

    I’m still shaking my head—30,000! That is more than 100 secrets checked into public, corporate repositories each day (on average, of course). Please, go through your org, make sure you are not contributing to this total. That is wild; even if you account for the fact that if an app has one secret out there, it probably has multiple; even assuming each vulnerable app had four, that’s still 7,500 apps exposing secrets in the most preventable way possible.

    So, if you’re not certain about your public repos, go get certain. The ROI on “a few minutes for a scan, or a couple hours for a person to search for them” versus “our AWS secret was compromised,” or, “our API key was discovered and abused,” is pretty high.

    And keep rocking it. The sheer volume of apps out there is part of the shared-secrets problem, as is the growth in use of secrets as automation and DevOps have taken over. But you’ve got the solution, just make sure they’re not hanging out there in a public repo. And then go back to doing what keeps the business alive.