devopsy.kinsta.cloud

Category: DevOps Practice

  • Predictions 2020: Application Trends, Opportunities and Challenges

    Predictions 2020: Application Trends, Opportunities and Challenges

    Without wheeling out all the usual clichés, 2019 has been another whirlwind of disruptive innovation and opportunity–with plenty of challenges to tackle and circumvent along the way.

    The threat landscape mutated with predictable unpredictability, multi-cloud app deployments are becoming mainstream fixtures and DevOps methodologies started exerting a newfound influence on business plans.

    The big question is what happens next? What anticipated app-centric trends will change the game and tear up the rule book (again)?

    Digital Transformation Takes Shape

    In 2020, we will see more organizations shift away from aspirational sloganeering to substantively embrace what can, and should be, a seismic step-change.

    Inevitably, business leaders will get more involved in application decisions designed to differentiate or provide unique customer experiences.

    Expect a new generation of applications that support the scaling and expansion of business’ digital models to emerge. This will include taking advantage of cloud-native infrastructures and driving automation through software development.

    Further down the line, digital transformation efforts will likely be AI-assisted, particularly as they leverage more advanced capabilities in application platforms, telemetry, data analytics and ML/AI technologies.

    End-to-end instrumentation will enable application services to emit telemetry and act on insights produced through AI-driven analytics. We anticipate that these distributed application services will improve performance, security, operability and adaptability, without significant development effort.

    The Rise of Application Capital

    Applications are now firmly established as the main conduit for companies to develop and deliver goods and services. They have become modern enterprises’ important assets.

    Even so, most still only have an approximate sense of how many applications they have, where they’re running or whether they’re under threat.

    This will soon change.

    To manage Application Capital effectively, it is essential to establish a company-wide strategy that sets policy and ensures compliance. This includes addressing how applications are built, acquired, deployed, managed, secured and retired. At a high level, there are six distinct and unavoidable steps that need to take place: build an inventory, assess the cyber risks, define application categories, identify the application services needed for specific activities, define deployment parameters and clarify roles and responsibilities.

    The primary aim of an application strategy should always be to enhance and secure all digital capabilities–even as their reach and influence shift and expand.

    DevOps’ Culture Club

    The technical minutiae DevOps methodologies and associated tools got a lot of publicity this year. 

    2020 will be all about getting the culture right, marrying theory with best practice and unlocking new levels of productivity without upsetting the operational apple cart.

    Culture is not optional. Team structure alone dramatically changes pipeline automation, with traditional single-function teams often falling behind their contemporary, DevOps-driven counterparts. 

    Consequently, we will see more collaborative team structures and alignment on key metrics that give NetOps additional means to focus on what the business requires: faster and more frequent deployments.

    DevOps has a 10-year head start on NetOps in navigating and overcoming obstacles around certain types of integration, tools and skillsets. Collaborative teams can explode the status quo by promoting standardization on tools that span from delivery to deployment (such as Jenkins and GitHub/GitLab).

    DevOps should not–and cannot–end with delivery. That means deployment functions–along with a complex pipeline of devices and application services–must be automated. This won’t happen without effective cultural realignment.

    The Data Center Is Alive and Kicking

    Conflating the adoption of SaaS with IaaS caused speculation that cloud was cannibalizing IT. Pundits warned that data centers would disappear. 

    The rumors were exaggerated. Data centers are still being built, expanded and run around the globe. The cloud hasn’t managed to–and likely never will–kill the data center.

    Early in 2019, an IDC executive told channel partners at the IGEL Disrupt conference that over 80% of companies they surveyed anticipated repatriating public cloud workloads. Security, visibility and performance remain common concerns.

    Repatriation-related opportunities include improving availability of multi-cloud operational tools and a push toward application architectures that rely on more portable technologies such as containers. 

    The data center is not dead. It’s just evolving. 

    Application Protection Challenges

    According to F5 Labs, the server-side language PHP–used for at least 80% of websites since 2013–will continue to supply rich, soft targets for hackers. Situational awareness is critical to mitigate both vulnerabilities and threats.

    Businesses are also realizing that applications encompass more than just the code they execute. Attention needs to be paid to everything that makes them tick, including architecture, configurations, other connectable assets and users. The prevalence of access attacks, such as phishing, are an obvious case in point.

    F5 Labs analysis of 2019 breach data confirms the need for risk-based security programs instead of perfunctory best practice poses or checklists. Organizations need to tailor controls to reflect the threats they actually face. The first step in any risk assessment is a substantive (and ongoing) inventory process.

    As ever, the industry will gradually incorporate emerging risks into business models. For example, cloud computing has gradually shifted from a bleeding-edge risk to a cornerstone of modern infrastructure. The risks associated with the cloud have either been mitigated or displaced to contractual risk in the form of service level agreements and audits. 

    API and You Know It

    The word is out. Application programming interfaces (APIs) can transform business models and directly generate revenue. Cybercriminals know this.

    More than ever, organizations need to focus on the API layer, particularly in terms of securing access to the business functions they represent.

    One of the biggest issues is overly broad permissions, which means attacks through the API can give bad actors visibility into everything within the application infrastructure. API calls are also prone to the usual web request pitfalls such as injections, credential brute force, parameter tampering and session snooping.

    Visibility is another major and pervasive problem. Organizations of every stripe–including IT vendors–have a notoriously poor track record of maintaining situational API awareness. 

    API security can be implemented directly in an application or, even better, in an API gateway. An API gateway can further protect APIs with capabilities such as rate limiting (to prevent denial of service attacks) and authorization. Authorization narrows access to APIs by allowing access to specific API calls to only specified clients, usually identified by tokens or API keys. An API gateway can also limit the HTTP methods used and log attempts to abuse other methods so you’re aware of attempted attacks.

    Appy New Year!

    All this is of course the tip of an increasingly interconnected iceberg. Any New Year’s resolution worth its salt should include a commitment to comprehensively master the development, deployment, operation and governance of application portfolio. The best way to do this, and to get visibility into the code-to-customer pathways for all applications, is to leverage a consistent set of multi-cloud application services. Here’s to a safe, innovative and transformational 2020!

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Vincent Lavergne

  • DevOps at Longtail UX

    DevOps at Longtail UX

    Longtail UX is an Australian SaaS startup that boosts traffic to e-commerce sites by automating the selection of relevant long-tail search terms and the creation of custom landing pages for each of those terms.

    The company has fully embraced the Infrastructure-as-Code approach, according to Troy Jendra, senior systems architect at Longtail UX.

    By using Terraform and Ansible for automation, “we can release whenever we want,” said Jendra. In practice, that can be at intervals between two minutes and as long as necessary at the other extreme.

    Jendra said he had not used Ansible before joining Longtail UX. He used Puppet in a previous role, but found it “painful.”

    “Ansible was a breath of fresh air,” confessed Jendra. It makes it easier to write configurations, and uses fewer CPU cycles because it does not need to run continuously. He explained that Terraform’s role is to spin up sufficient infrastructure so Ansible can run.

    A recent project added support for CJK (Chinese, Japanese, Korean) characters to Longtail UX as part of a push into the Asia market, and that made it necessary to clone part of the infrastructure. Thanks to Ansible and Terraform, that task was easy to perform and completed in just half an hour. Thus, Longtail UX brought the new capability to market more quickly than would otherwise have been possible.

    Ansible and Terraform together form “a cornerstone of our disaster recovery plans,” said Jendra. Fully automating recovery to improve on the current worst-case time of a few hours would take more time and effort than justified.

    Apart from that, “it’s important to automate as much as we can,” said Andreas Dzumla, Longtail UX co-founder and CEO.

    Avoiding Vendor Dependence

    Even though Longtail UX runs on AWS, a deliberate decision was taken to avoid the vendor-dependency that would come from using AWS-specific services, such as AWS CloudFormation, in place of Terraform.

    For the same reason, the company keeps things as simple as possible and sticks to AWS basics, such as EC2. It has recently started using Spot Instances to reduce the cost of running certain batch processes.

    Jendra keeps a watching brief on AWS Lambda, and while the company does not currently have a use case he does see a time when it will jump from EC2 to Lambda.

    “We’re pretty locked into AWS,” he admitted. However, the company uses AWS-specific services only where the benefits clearly outweigh the lack of portability. He likened the situation to 1990s attitudes toward using Microsoft-specific technologies.

    Growth

    The adoption of Kubernetes is not on the cards due to the relatively small size of Longtail UX’s DevOps team.

    “We’ve doubled the size of our development team in the last six months,” said Jendra. It now comprises seven developers, a project manager and himself.

    Dzumla expects it will double again in the next 12 months.

    Jendra predicts that improvements to Longtail UX’s development stack will make it easier to on-board new hires.

    “We currently utilize a Vagrant/VirtualBox dev stack (hooked into the aforementioned Ansible configuration), but find that very rough around the edges, and I only see it get worse as more attention is focused on Docker,” said Jendra.

    DevOps is a philosophy, not a role, he emphasized. “Either everyone is doing DevOps or it doesn’t work.”

    Fortunately, that understanding goes to the top of the company.

    “Everyone needs to pitch in,” said Dzumla. “We do a lot of things that haven’t been done before, so we need senior people who don’t merely expect to do what they’re told.”

    — Stephen Withers

  • Predictions 2020: Five Real-Time Data Predictions

    Predictions 2020: Five Real-Time Data Predictions

    According to Gartner, 85% of big data initiatives end in failure. In 2020, organizations are out of budget and operational runway, and need to start executing and getting the big data recipe right.

    It is not just about big data; it is about using data differently. Rather than rearward-facing business intelligence, leading companies are driving differentiation and profit by using data to make fact-based decisions in real time. This requires the broader application of real-time information to make a difference in user experience, in prioritization of production and manufacturing schedules, and in spotting problems before they happen.

    Rather than reports for a few people, the new data-driven business processes are engaged continuously, and across all customer engagements, transactions and decision points within business processes. Scale means throughput across millions of transactions and with potentially millions of customers. Database systems have to be engineered differently, with different technology built to deal with real-time demands and high throughput across huge numbers of endpoints.

    As we enter the next decade, here are five predictions, centered on real-time data, that we expect to emerge.

    Machine Learning and AI Models Finally Get the Data They Deserve

    Most AI and machine learning initiatives are niche, nascent and not operating anywhere near scale. According to industry research (O’Reilly), hardware and data are the primary bottlenecks in getting enough data processed fast enough to harness the full promise of AI. That’s changing, with the arrival of new wire-speed hardware (from companies such as Intel) and clever data platforms designed to leverage hardware innovations for real-time efforts on a massive scale. It’s all about the amount of data you can process in real time to make AI and machine learning actually work. This is what is needed, and it’s becoming practical.

    Privacy Prompts a New Era of Data Innovation

    Businesses hoard data. And often, so much of it isn’t used due to infrastructure costs and technology bottlenecks. Now, as new privacy laws (GDPR, CCPA, etc.) show their teeth, companies really need to make all that data worth the risk. It will drive new real-time business processes that are not only safer but squeeze value out of data in new and exciting ways.

    Companies face a delicate balancing act. They must comply with the realities of new regulations, while also being able to use personal data in real time to serve customers what they want and expect. Companies that can satisfy the regulators and appeal to customers will win.

    If an Economic Downturn Occurs, Data Will Drive the Next Round of Economic Gains 

    An economic downturn is inevitable. When it happens, companies will be asked to do more with less. As a result, they will need to completely rethink their solution and delivery strategies.

    In that environment, with fewer markets opening or providing a sufficient return on investment, the next wave of gains is to optimize your existing segments and operations to the fullest extent. These data-driven initiatives require that companies understand customers better, and be able to instantly target them in critical moments—harnessing massive amounts of data to suggest and expand purchases. 

    5G Will Accelerate Customer Expectations

    As bandwidth increases and high bandwidth communication becomes available across devices (on cars, planes, homes, ships, buildings, etc.) and in more situations, we will see data being used differently. What may have been processed intermittently in batches with high degrees of latency will now be processed in real time, driving higher efficiency and removing risk from supply chains, customer interactions and equipment maintenance and performance. It will no longer be OK to know how you’ve done and correct it next quarter; rather, things must be corrected in near real time. New standards will be set by the highest-performing companies, and entirely new businesses will emerge that are leveraging a new level of availability to real-time data.

    Decline of Globalization Will Force Companies to Know Their Customers Better

    As global markets shrink, it becomes imperative for companies to up their game and drive for more market share within the available market. Companies that have been treading water and growing at the rate of the global market expansion are going to start to shrink. Differentiation through better customer experience and better management of supply chains will make the difference between continuing to grow versus stagnation or shrinkage.

    Companies that have invested in instrumenting their supply chains, who have a deep understanding of what comes from where and what the alternatives are, have already begun to optimize around the new web of tariffs. Those that are less agile are seeing reduced profits or reduced sales based upon the elasticity of their pricing options.

    The more real-time data one has, the clearer the picture of what options are available as the global situation changes. The faster a company can process that data means either missing financial targets or outperforming peers.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Lenley Hensarling

  • App Mobility Is the New Use Case

    App Mobility Is the New Use Case

    Selling increased investment in DevOps is not always easy. It takes time to implement, resource away from other projects and inevitably there is cash outlay. If not done carefully, it also appears to introduce chaos, something most of us in IT strive to avoid.

    But the benefits, at this point, are easy to document. Plenty of companies have tried and succeeded in moving to a more agile/DevOps approach to deployment. Yes, companies have failed, but the publicly acknowledged failures have also been dissected for lessons learned, which can help in your transformation.

    Every advice site suggests tying DevOps/digital transformation to business goals, which is a good idea, but is harder to do most of the time.

    Not any more. The truth is the future is mobile. Not as in mobile phones or cross platform (though both have a place in the future), but in the ability to run an app where it makes the most sense today with the knowledge that tomorrow there might be a better place to run it.

    Historically, the architectural choices of yesterday’s teams become a burden on today’s teams. I’ve worked at a major insurer where a mainframe flat file DB system was keeping an application from moving. I’ve worked at a power company where we were not allowed to modify a system running on OS/2 because no one quite knew how to maintain it. I’ve worked at an energy services company where I spent a year trying to re-create Novell IPX solutions in an Ethernet environment…The list goes on.

    What if we could avoid leaving such a legacy to future teams, and be more responsive to business needs/profitability in the future? That is, in a nutshell, what containers offer you. Today, you are running your app internally in a container management system. Tomorrow you’re running it on AWS in a container management system.

    There are things to watch out for–most vendor-sponsored container management makes it very easy to use containers on their platform of choice, but difficult to move containers. IBM, as one of the least intrusive examples, offers integration with their proprietary tools. Once you’ve taken those integrations, your mobility/options are more limited. As I mentioned, IBM is one of the more open companies out there. They offer value for tying you down, but if you don’t need those services, it’s better not to use them so you can move the application at will.

    Situations change, and containers allow for those changes. You may have a huge budget for external cloud apps today, but reasons ranging from internal cost decisions to regulatory changes could force your organization to reconsider options in just a few short months.

    That makes mobility important to business. So does cost management. No matter what the cheapest architecture to deploy on tomorrow is, wherever makes the most sense is going to be a hit.

    But how portable are they? Depends upon the app, and the implementation. An application that is developed as a group, able to run in a single pod (or multiple exact copies in multiple pods) is an easy thing to move about. One with containers spread across a variety of platforms, each doing what it is best at, will be more difficult to move. Persistent storage kind of guarantees that most enterprise apps have limited mobility–at least for the time being.

    Any app that can be moved to the cloud can be containerized first, granting mobility that means no need for massive conversion efforts if the cloud doesn’t work out. Any app pulled back from the cloud to the DC has the same potential, the issue of where the data lives is real no matter what architecture is chosen for implementation. But for any app that can be moved, it can be put into containers and moved far more easily in the future. For many apps, it is simply dropping it into the new environment and configuring networking to route traffic to the new location.

    We’re already going to leave future teams with a hodge-podge of databases, programming languages and networking tools such as WAF/load balancing. Let’s make life a little easier on them, and help increase the use of DevOps, by deploying with containers and targeting whatever makes sense for the org today, secure that tomorrow that can change and our burden will be less than it might have been.

    — Don Macvittie

  • Social Media Marketing for Businesses

    Social Media Marketing for Businesses

    There are over 3 billion social media users worldwide, and over 70% of successful marketers are convinced that social media have, in one way or the other, contributed to their businesses’ exponential growth. Perhaps this is what makes social media a preferred marketing medium for small and medium-sized businesses (SMBs) and corporate businesses as well.

    However, one primary concern is if it’s worth investing in social media marketing for your business. Should it top your list of marketing strategies for the New Year?

    Well, to some extent, your decision here will be influenced by the audience you’re targeting, but then marketing on social media is certainly something you shouldn’t ignore. To help you get started with marketing on social media, we’ll touch on:

    1. Social media marketing definition.
    2. The benefits of social media marketing.
    3. How to do social media marketing the right way.

    Let’s dive in.

    What’s the Meaning of Social Media Marketing?

    Social media marketing (SMM) is utilizing social media websites and platforms to promote your brand. These platforms include Facebook, YouTube, Twitter, Instagram, Reddit, Pinterest, etc.

    Usually, the primary goal of utilizing these mediums is to create captivating content and infographics that users on these platforms can share on their social networks. You can post videos, texts, images and updates, etc. to drive engagement on the site and keep it active.

    This will be crucial in helping you boost brand exposure and, most importantly, increase conversions. Now, getting started with social media marketing for your business is easy, but if you wish to build a solid brand reputation, the security of your audience comes first.

    There are lots of ways you can ensure your audience’s security, for example, advising them not to share their confidential data, such as login details, with strangers. Still, you must also do your part to help them preserve these data. One of the foolproof ways of doing this is ensuring that your business website is fully encrypted with SSL certificates.

    An SSL certificate, in this case, will ensure all the data shared on the site are fully encrypted and kept out of reach of cybercriminals who might be trying to steal confidential data like credit card details that are shared on your website.

    What Are the Benefits of SMM?

    Let’s take a step back in time to two decades ago when there was no social media. Interaction with people over long distances was a nightmare–same for a business struggling to build a client base.

    Before the 1900s, you could only use letters to pass messages across long distances. It was almost impossible for startups to build a following.

    Fast forward to the late 1900s, when social media was introduced; businesses have leveraged different forms of communications, including emails, to connect to prospects. While email marketing isn’t dead yet, social media have revolutionized the entire marketing industry.

    Here are just a few benefits of SMM:

    Boost in Website Traffic

    Website traffic is the holy grail of any successful online business–and it doesn’t matter much whether it’s organic or paid traffic, so long as there’s conversion. With a proper ad targeting technique, social media will give you the dream client base of people that are solely interested in your products.

    Besides, it also boosts your overall search engine rankings. If you share captivating content that is shared by most people, you get more inbound traffic, something which is bound to improve your SEO rankings because the search engines will see your brand as a reputable one.

    Increased Brand Awareness

    The brand awareness aspect here still touches on the type of content you share online. This means that if you want to attract a large following, it’s always crucial that you focus on the content you share online, ensuring that it is one that resonates with your target audience.

    People will always share content that offers solutions to their everyday problems. They will also share content that is appealing to their eyes, and if you can produce such kind of content, you’ll surely get the word out about your business in several social circles.

    Social Media Marketing is Cheap

    Think of TV ads and billboards, etc….While it may be a bit costly and a little difficult targeting a specific audience with TV ads or billboards, social media marketing is way more direct and cost-effective.

    For example, if you wish to use a medium such as Facebook, you’ll be able to choose the audience you want to reach. Besides, the costs are affordable, and you can easily reach a wider audience with a smaller ad budget.

    Increased Conversion

    Most brands prefer the use of how-to videos, guides and real customer testimonials on these social media platforms to promote their brands. This way, the businesses do humanize not only their brands, but also offers a smart way of solving problems.

    This strategy increases conversion because it gives the target customers a desire to use a specific company’s products or services.

    It’s Flexible

    You are not restricted to connect with your audience to a time. With social media marketing, you can always tweak your schedules to get the most time with your target audience.

    Besides, there are lots of free and paid SMM tools you can use to schedule posts, so they go live when your audience is most likely to interact with them.

    How to Do SMM the Right Way

    Just like any other technique, SMM also has its fair share of challenges. Before getting conversions, improved brand awareness and web traffic are things that will be hard to come by for you and you need to mull over below three pillars for running a successful SMM campaign.

    Set Your SMM Goals

    Setting your goals will make it easy focusing on your strategies. Your goals should be tailored on a mission to post content on your site not just for promotional purposes, but to drive awareness about the business.

    Most importantly, you should focus on connecting with prospects and building a relationship with them. If you don’t know where to start, check your peers and feel free to copy and try something that works from them.

    Choose a Target Social Audience

    SMM was designed to be used as a targeted marketing strategy. This is not the time to try the old spray and pray techniques.

    Identify your audience and post content that resonates with them. You can use social media tools to help you understand your audience’s behavior and trends, so you’re always up to date with current events.

    Plan Your Posts 

    It’s not all about scattering content at any time on social media. Veteran marketers believe that planning your posts will help you come up with insightful content that will offer a solution to the audience and spur up engagement.

    You can also schedule your posts and only post them at times when your prospects are active on social media. It’s also recommendable that you check analytics to understand your audience’s behavior and come up with something that will put you on the same page with them right away.

    Bottom Line

    Building a following and increasing conversion with social media shouldn’t be a tough job. If your strategies aren’t delivering 100%, consider tracking your competitors and use A/B tests to find out the plan which works best for you.

    — Wendy Dessler

  • Moving Things Around: The Acquisition of Protego

    Moving Things Around: The Acquisition of Protego

    I received a note from Protego Labs’ vice president of marketing about Check Point Software acquiring Protego. We see a fair number of acquisition announcements, and usually don’t write about them–though we read them and stay abreast of industry happenings.

    I used to follow Check Point, and haven’t looked into what they’re doing in a while, so I followed through links to both organizations and looked at their products.

    I found myself becoming the wizard that some call Tim. But instead of “What is your name? What is your quest? What is your favorite color?” I was looking into “Where is your site? What are your products? What value do you add?” My beard is kept trimmed, more along the lines of a knight’s, so it makes sense I would ask different questions. As long as I’m not spouting “It’s just a flesh wound,” I figure I’m doing okay.

    First off, this merger makes sense. Protego does it for serverless and Check Point is doing their best to be where your code is running. Indeed, Protego probably needed a merger of some kind because all they do is serverless. Check Point’s Cloud Guard Dome 9, by contrast, will protect access rights and data for serverless, but doesn’t do what Protego does–keep an eye on the code. So this is a good fit.

    But it once again brings to light an interesting issue as you move things from DC to cloud A to cloud B to serverless. Where are your support functions? Networking, security, storage…These things need to be where the code is, but architectural options are more than they’ve been for decades. And the architectures are largely incompatible. Consider network functions for a physical-server based DC versus a VM DC, versus a Container DC, versus Cloud…You get the idea. The array of functionality and where it runs is different. Different in implementation and different in maintenance.

    This was a problem I (and others) pointed out when cloud started taking off: more work for ops, even if some of it is automated. Turns out ops, storage management and security all have more work, because all of those items are handled differently in the different architectures. And Protego had to focus on one to get it right, meaning they needed some kind of merger in the long run.

    So do you. Adding more and more work to ops–be it DevOps or traditional ops–is not the answer. A plan for standardizing is necessary.

    That is one of the big promises of containers, in my opinion. Not only are they more agile and easier to use in a DevOps environment, they are relatively standardized. Ops will still have more work if you’ve got apps in several of those architectures, but containers obfuscate some of the differences and allow standardized networking within the pod/node/group, for example.

    Some functionality just doesn’t fit into containers–you still need a physical network in the DC, or to configure the virtual network in a VPC to get traffic to/from your containers–but much of it does fit. Once at the pod/group, networking is virtual and the same regardless of where the containers are running. Which reduces overhead while making changes easier. The same is true for security, and increasingly for storage.

    There are great companies out there tackling these issues, and I’ll look at them on occasion. Right now, I know my former employer F5 Networks is working to solve the networking services/performance/security issues, and taking advantage of NGINX to handle some parts the core org traditionally hasn’t addressed. There are other companies, I just hear about that one more because I am still very close to some F5ers.

    It is worth planning for and certainly worth looking into more portable options, anything that lightens the load and keeps your great apps running. Keep kicking rear and spinning up apps.

    And don’t call me Tim.

    — Don Macvittie

  • IBM Z Open Editor Support for Language Server Protocol is a Game Changer

    IBM Z Open Editor Support for Language Server Protocol is a Game Changer

    The integrated development environment (IDE) is an indispensable tool for software developers. Before it came along, coding was a laborious, detail ladened undertaking. We’ve become accustomed to the syntax checking and code completion features than even the most basic IDEs provide. These days we tend to forget how hard it was programming with nothing but a rudimentary text editor. Something as simple as finding a missing comma or a misplaced curly bracket that was causing a compilation error could take hours, maybe days should the codebase be big enough. When it came to tracing your way through a seemingly endless chain of functions and classes in order to find the culprit of a runtime error, well…fuggedaboutit! Without the modern IDE, we’d be sunk.

    Well, that was then and this is now. A few years back, a new technology emerged on the technical landscape that’s boosting the power of the IDE, and subsequently the scope of work a developer does and the decisions he or she makes by an order of magnitude. This new technology is Language Server Protocol (LSP).

    LSP Takes the IDE to a Whole New Level

    LSP is a specification developed by Microsoft that standardizes the way certain typical features are implemented within a programming IDE. LSP attempts to consolidate the implementation of IDE commonplace features such as code completion, hover-over tips, jump-to-definition, find-references and syntax checking into a standard format that can be applied to any IDE in an agnostic manner.

    LSP is a technology designed to address the following problem. Imagine that a tools vendor has an idea for implementing a new plugin that will automatically do code completion for programs written in the COBOL programming language. Such a feature might be useful to any number of COBOL programmers. However, not every COBOL programmer is programming using the same tool. Some might be using an IDE such as IBM Developer for z/OS. Another might be using a text editor such as Sublime Text, Atom or even something more basic such as vim. In earlier times, in order to get the feature to market the vendor needed to implement different versions of the plugin in a way that was special to the given development environment. There’d be a team working on a Sublime Text version of the plugin, another team working on the vim plugin so forth and so on. Not only did the tool developer need to accommodate different operating systems, but each team might come up with its own, particular way to implement the feature. As team members left the company and new members arrived to replace them, those new developers needed to learn each particular way the feature was realized. As you can see, not only did the variety breed complexity, but things got very expensive very quickly.

    LSP does away with the need for such specialized tools development. LSP provides a standard protocol that can be implemented in any tool. The protocol defines a set of standard methods, objects and communication methods that provide a common set of services in any IDE.

    Thus, the only work that needs to be done to get the previously described COBOL code complete feature to market is to express it in a way that is compatible with the LSP. The actual work of realizing the feature then involves writing a client that supports the standard. It’s a “one ring to rule them all” process so to speak.

    The LSP specification was originally published by Microsoft specific. But the standard has been embraced as an industry-wide. There are implementations in Java, C++, C#, Python, Scala, Swift and PHP, to name a few. Also, there is an implementation of LSP for COBOL under z/OS, which brings us to IBM Z Open Editor.

    Bringing the Use of LSP to the Mainframe

    IBM Z Open Editor is a free Visual Studio Code extension that provides a state of the art programming experience for COBOL and PL/1 developers. Also, IBM Z Open Editor integrates with Eclipse Che and Eclipse Theia. Integration with Eclipse Che and Theia is particularly interesting because it enables browser-based editing. It’s a powerful tool, even more so given that historically COBOL and PL/1 programmers have lived in the backwaters of modern IDE development. IBM Z Open Editor makes IDE-based software development a general programming experience. Developers can use the same tool to program COBOL as they do in Java or even HTML for that matter.

    LSP Enabled Features in IBM Z Open Editor

    The following is a list of tool features available to mainframe programmers using Visual Studio Code with IBM Z Open Editor enabled:

    • Code completion.
    • Hover over instructions and snippets.
    • Jump to definitions.
    • Workspace symbols.
    • Find references.
    • Diagnostics and syntax error detection.
    • Outline view.
    • Previewing of included copybooks on hover.
    • Navigate to copybooks.
    • Code template snippets.
    • Refactoring such as “rename symbol.”
    • Variable completion.

     Using a single IDE to program in a variety of languages is a trend that’s been evolving for a while. However, adding LSP into the mix allows any IDE to present a consistent set of design time features. For example, one IDE is now able to do code-completion, hover-over reporting and variable tracing regardless of the programming language in play.

    For example, Figure 1 below shows the COBOL code completion feature of IBM Z Open Editor plugin for Visual Studio Code. IBM Z Open Editor uses LSP to facilitate code completion.

    Figure 1: IBM Z Open Editor uses the Language Server Protocol to facilitate context-sensitive code completion.

    Figure 2 shows the search and sort features of IBM Z Open Editor, which again implemented according to the LSP.

    Figure 2: Using LSP to implement IBM Z Open Editor’s sortable and searchable outline view for navigation.

    Finally, Figure 3 shows how the IBM Z Open Editor takes advantage of the extensibility capabilities of LSP to implement a feature that resolves and loads copybooks for preview. A copybook is code that can be copied from a master source and inserted into several different programs or into a variety of places in a single program. A copybook is used to define the physical layout of program data, variables for example, as well as instances of procedural code.

    Figure 3: IBM Z Open Editor extends LSP to review and load a copybook within Visual Studio Code.

    Clearly, LSP brings a lot of power to the mainframe programming experience. Now tools developers can create a unified programming experience using a common methodology. But where things really get interesting is when LSP is used to report data that goes beyond standard programming and code management activities, to a place where the real-time behavior of those using deployed code is being reported. In other words, LSP makes it possible not only to get information about code that is local to the developer’s desktop but also about the code as it is being used at runtime out on the internet.

    Beyond the Mainframe: The Long Term Significance of LSP

    LSP is extensible by design. As you read above, IBM Z Open Editor extends LSP to allow programmers to preview and load copybooks. This is done by extending the protocol.

    The typical IDE to server interaction under LSP is that the LSP client reports to the LSP server when a code document has been opened, changed, saved and closed. Then, once the LSP server is aware that a code document is in play, the server can inspect the document and report back events that are relevant to the programming language (Figure 4).

    Figure 4: LSP uses a predefined set of commands and request/response objects to support programming IDE is a language and operating system agnostic manner.

    For example, the LSP server can inspect the document to make sure the code is syntactically correct. If an error is encountered the server reports back the starting and ending location of the error, along with a message. In the case of the copybook review feature, the client reports back the location of the cursor in the code window and the server determines an opportunity for a copybook review and informs the client accordingly.

    While the copybook preview feature is powerful, it’s confined in scope to the immediate document. This is good. But, imagine what it would be like if the server had knowledge of all instances of the code deployed and running on computers connected to the internet?

    Suppose for example, that your code was powering an API running on the internet and you had the ability to learn about the number of calls to a particular function backing the API or better yet, imagine that you had the ability to learn about function calls that encountered particular problems, such as a pattern of mistyped parameters or high latency calls. Then imagine if that global runtime behavior was reported right in the IDE? Such information would change the very nature of how a programmer approaches his or her work. More importantly, it would change the way an enterprise manages programmers.

    What if a programmer could decide what to work on based on global runtime behavior reported into the IDE via an LSP extension? For example, going back to the imagined pattern of mistyped parameters, let’s say that when a developer hovers over the related function in IDE a warning icon appeared informing the developer of 1000 instances of mistyped called were made at the global level. The developer decides that such an error rate is unacceptable. Then, he/she examines the developer documentation and discovers that the parameter type definitions for the function are poorly described and that the document needs to be corrected. The developer then makes updating that developer documentation a critical path, part of the day’s work that needs to be delivered immediately.

    Given the power that LSP brings to the programming experience, such a scenario is entirely possible. In fact, there are companies out there such as Apollo Graph Manager that presently allow developers and third parties to register their production APIs in order to collect the sort of global information described above and have it reported in an IDE via LSP. As those of us who have been in the software business for a while have come to learn, once a feature such as global reporting catches on, it’s only a matter of time until it becomes an industry-wide practice. It’s only a matter of time before globally collected runtime metrics delivered to a programmers LSP become commonplace.

    Again, the ramifications are significant. Once a programmer has the ability to make fundamental decisions about feature development and deployment schedules, what then becomes the role of the project manager and the product manager?

    To take the issue one step further, how much power should a programmer be given? And in terms of general business practices, how much should the programmer know about a company’s products? These questions might seem fantastic, but keep in mind at one time companies guarded their source code as a trade secret. Today, more code than not is shared between companies as part of the open-source movement. As a result, the way code is made and a developers work has changed. The same possibility exists due to the growing trend to extend the capabilities of the LSP. The ramifications of LSP go well beyond simply reporting syntax errors and doing code completion. LSP will change the way the entire industry works, from mainframe programming to developers working in the cloud or on commodity hardware.

    Putting it All Together

    Given current trends, there’s little doubt that LSP will make even the most rudimentary code editor a powerhouse tool for software development. Standardizing IDE features into a common format allows new features for any development tool to be implemented faster and at a reduced cost. In no time at all we might even figure out a way to use LSP to make is so large bodies of code can be written automatically with just a few guiding keystrokes from the developer’s keyboard no matter the programming language. It’s a real possibility.

    Not only will LSP making coding easier and faster, but it’s also going to change the role of the software developer. Once all the code running on the internet becomes LSP aware and accessible, developers will get runtime information about how their code is performing at runtime on a global level. The trend is already in play. As history has shown, the further down a technology goes into a given population, the more powerful that population becomes and the greater the ramifications when the power is exerted. There’s a very real possibility the information that LSP enabled IDEs provides will make the day-to-day programmer more prominent in the product decision-making processes that are presently the responsibilities of program and project managers. Once that shift takes place we’re likely to see another industry-wide transformation take place in the way software is made and delivered. History has shown that such transformations have long term benefit, but in the short term are disruptive and disturbing. We’ll do well to be prepared.

    — Bob Reselman

  • The Use of Feature Flags in Code: Too Many Flags?

    The Use of Feature Flags in Code: Too Many Flags?

    It is interesting to watch the growth of an idea over time. The idea of using flags in code to do different things is as old as programming itself. Old-school configuration files used them, and they worked, so they were adapted.

    Thing is, given an idea that works, humanity inevitably takes it too far, and flags to control software behavior seem to have reached that point. If you are using one set of flags for A/B testing, another to segregate code in development at runtime, another to turn functionality on for some users but not others and yet another set of flags to hide data based upon user…You’re buried in unnecessary code branches. If your organization isn’t great about cleaning up after flags are no longer needed, you are building spaghetti code that future developers will not thank you for.

    The best answer to this growing burden is focus. What is the best use of feature flags/toggles in your environment? They certainly speed the delivery process by having the code there, in nightly builds, just not executed until the flag is flipped. This helps in rollout also by allowing operators to turn a feature on when it is ready by changing config rather than redeploying the application.

    For A/B testing, in many cases it makes more sense to handle switching at a load balancer, where again it is a config, but separate instances serve the UI in question. This, like all decisions regarding flags, should be based upon the volume of change. Changing the contents of a list is likely easier to test with flags, but large volume of change is probably better run separately and switched off of a load balancer.

    The same is true with the volume of change in source. A rollout might be the best option for handling large volumes of change, and feature flags may simply create more complexity.

    As with everything, approach the problem with a plan that works best, in this instance, in your environment. There is no denying that the ability to turn on a new feature and then turn it off if something goes wrong is appealing, just use the idea judiciously. And clean up after yourself. No shop that uses flagging extensively will say “yeah, we don’t clean it up,” because the mess of nested checks for flags would slow the code and make it passingly difficult to even read, let alone maintain, over time. So approach it from the beginning with “It is a tool, and when it no longer serves its intended purpose (the feature is fully live or abandoned), we remove it.”

    And keep rocking it. You are the engine of business, and this is what you do. Make it great and keep it running.

    — Don Macvittie

  • The Benefits of Test-Driven Design

    The Benefits of Test-Driven Design

    At John Hancock, we use Test-Driven Design (TDD) for all our new initiatives. TDD has three simple steps:

    1. Before you write functional code, write a test that proves if the implementation works or fails.
    2. Write the code and watch the test pass.
    3. Check if the added functionality changes your holistic approach and if you want to consolidate/refactor some of your code. If yes, refactor these sections.

    That sounds simple enough, so why write an article about a three-step process? Why do we, at John Hancock Digital Enablement, get so excited about TDD? We have seen major impacts to our developers, products and culture:

    • Increased motivation and self confidence.
    • Shorter Release-Cycles.
    • Increased Code Quality.
    • Massive Reduction of Bugs in Production.

    The Foggy Path

    Imagine your development process like a foggy path, where you can see directly in front of you, but anything further away becomes foggy and imprecise. Imagine it like a journey into the unknown.

    Obstacles may appear suddenly, forcing you to rethink your approach (refactoring), or you may get above the fog after a long journey and realize that there is a much simpler way to reach your goals (also refactoring).

    This uncertainty and constant change may appear to be frightening and trigger anxiety, but TDD is the safety net, because you know that what you’ve built holds up against all the risks that have been identified. As a developer, I can take much higher risks and try different approaches and get quick validation.

    The test cases built out as part of the TDD flow are ideally integrated into a continuous integration/continuous development (CI/CD) Platform, giving fast and reliable feedback to the engineers about unexpected behaviors their code change may have caused. Because the feedback to the engineer is near instant, the developer is familiar with the change that caused the error and is able to resolve it rapidly. 

    TDD Is the Opposite of “Never Change a Running System”

    A well-known issue is that the later a bug is found, the more costly it is to resolve. TDD enables fast feedback loops so bugs can be resolved quickly and cost efficiently.

    As an application grows, TDD gives you a solid foundation of everything that has already been built. You can be confident that what you have built is solid and that new functionality can be added to it easily and without taking the risk of breaking everything. In other words, TDD is the opposite of “never change a running system” and enables us to build even better software. 

    TDD Always Provides Up-to-Date Code Documentation

    TDD provides excellent documentation toward the requirements and behaviors of the application. While documentation always lags behind the functional code and typically is written after a functionality is implemented, in the world of TDD everything starts with a test. The test documentation is always up to date and gives developers an easy and understandable way to figure out what the application is achieving without dissecting the entire code.

    The following quote from Terry Pratchett explains it best: “If you do not know where you come from, then you don’t know where you are, and if you don’t know where you are, then you don’t know where you’re going. And if you don’t know where you’re going, you’re probably going wrong.”

    As an application grows, evolves and is built up over time, and as it’s passed down and handed over, TDD gives it documentation and describes its solid foundation. The act of writing a test case forces a developer to stop and think about the functionality that is to be implemented and describe its desired outcomes.

    TDD Provides Early Feedback 

    Through TDD we receive early feedback about the path we are about to set foot on. Early indicators can help us correct our assumptions or help rephrase or rewrite a requirement so that we deliver customer value. 

    Early indicators that we’ve encountered: 

    • Functionality cannot be measured: Why are we implementing this if we cannot measure its outcome?
    • Functionality does not add any value.
    • Functionality cannot be tested: Similar to the first bullet, if a functionality cannot be tested, how can we accept it’s delivery? 
    • Functionality can be easily embedded into an existing part of the application that needs refactoring: This can trigger the refactoring before we start the implementation.

    As described, it is very helpful to think about the steps ahead before jumping in, which can be difficult for engineers to do. TDD does so in a language that is natural to engineers.

    TDD Embraces an Ever-Changing World and Removes Fear of Change

    TDD as a part of eXtreme Programming (XP) accepts and embraces an ever-changing world we cannot control. Changes may cause discomfort and anxiety as planning becomes difficult/different.

    In an unstable, disorganized software project, changes are thrown at it, a solid foundation is missing, testing is skipped or postponed to the end and refactoring is skipped all in the name of on-time delivery. The first delivery of the application may be on time, but as time goes on the anxiety grows, there are random bugs everywhere, the more bugs that are fixed, the more issues pop up and you essentially end up playing a game of whack-a-mole in which you will never be in control.

    In a project that embraces XP principles, such as TDD, we try to remain in control from the beginning, facing challenges early so they do not bite us later on. A solid test base gives developers, and everybody else on the team, confidence that the delivered solution will work, but most importantly it removes the fear of change.

    Without fear of change, we can try all sorts of crazy things, test out ideas and see them turn out or fail without the code failing, without losing a customer, without getting that phone call in the call center. 

    Traditional QA and Release Cycles Are too Slow for this New Era of Ever-Changing Needs

    As software grows, its testing becomes more intense. So, with each new piece of functionality there must be a corresponding test case. The manual execution of those tests becomes lengthy, the feedback loop to the developers slower, releases get held up, customers do not get new functionality in time and, in the end, money is lost.

    Traditional QA and release cycles are too slow for this new era of ever-changing needs. What if I want to release daily or weekly? Do we have to execute the test procedures every time? What if bugs are found and repaired? Do we need to rerun the entire set? 

    The answer is yes—but if a machine does it in a few minutes, who cares? 

    While I am not a proponent of no human testing, what I am saying is that 95% of manual QA can be automated and executed by a machine, and TDD provides a fantastic test set to get started with. Humans may catch errors that are hard for a machine to identify or imagine since human behavior is hard to predict, so spot testing as well as exploratory and behavioral testing are still needed.

    We Are Left with a Team that Is Hungry for More and Only Afraid of the Enormity of the Possible

    What are we left with at the end of a TDD project? We have a well-documented, easy to understand, easy to change and stable code base lead by a team that is not afraid of change. We are left with a team that is hungry for more and only afraid of the enormity of the possible.

    — Niklas Studer

  • Waging a Winning WAR in AWS

    Waging a Winning WAR in AWS

    Above all other security advice for enterprises working with Amazon Web Services (AWS), there is one resounding war cry: “Go to WAR.” WAR is an acronym meaning Well-Architected Review. It’s a powerful and proactive way to mitigate real risk with the AWS team and its partners. If you’re using AWS (or thinking about it) consider adding WAR to your security arsenal. It’s a well-kept secret starting to proliferate in the cloud industry for reasons you will find obvious after reading this article.

    AWS Promotes a Shared Responsibility Model

    When it comes to cloud environments, a common term that is often heard and used across all cloud service providers (CSPs) is “shared responsibility model.” This model most often dictates terms of Master Service Agreement with any potential CSP, be it a Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) model. The goal is to clearly identify and establish the security responsibilities that are shared between a CSP and cloud consumer. 

    As security experts, Wallarm advocates for the shared responsibility model. It is impossible for a cloud provider to provide 100% security for you, like in securing your customer’s data and access (you can see this in the AWS shared security model below). There are also enormous benefits to application and API security to having both the CSP and cloud consumer putting up a strong defense. All customers on AWS and other cloud infrastructures should be proactive agents in their cloud security. (See Securing Apps on AWS with Wallarm.)

    This visual image depicts how shared responsibility is distributed:

    It Starts with Well-Architected Frameworks for AWS Cloud Architects

    AWS Developed the Well-Architected Framework to help cloud architects build secure, high-performing, resilient and efficient infrastructure for their applications. Based on five pillars—operational excellence, security, reliability, performance efficiency and cost optimization—the framework provides a consistent approach for customers and partners to evaluate architectures and implement designs that will scale over time. 

    AWS’s Well-Architected Framework approach is built on the shared responsibility model that helps consumers and providers truly understand their portion of responsibilities, as outlined in the figure below.

    The framework was intended to be far more than an architected tool for AWS. It was designed as a sort of way of life and method of looking at your architecture to ensure resilient and consistent outcomes. 

    The Well-Architected Framework is a living set of best practices that AWS continuously updates. Every time you think about starting something new or changing something, use the five pillars to evaluate what you are proposing. This is where WAR comes in.

    Approaching the WAR of Cloud Security

    The WAR is a systematic approach to review your architecture—whether already in AWS, on-prem or even in other cloud providers. WAR is currently a set of 46 questions, which could shift in number since this is a living methodology. It is  aligned to the five pillars mentioned:

    • Security. 
    • Reliability.
    • Performance efficiency. 
    • Cost optimization.
    • Operational excellence. 

    Answering WAR questions helps identify which areas fall into three categories: 

    • Well-Architected.
    • Need Improvement.
    • Critical Issues.

    Critical issues should be remediated immediately. These are things such as not using multi-factor for your accounts or exposing data to the public. Need Improvement items should be looked at over a three to six month time period. 

    AWS recommends that you perform these reviews periodically (at least every six to 12 months) on each critical workload. Even items that are deemed Well-Architected today can change due to changes in your environment or new options that replace the way you are doing things today.

    How to Go About a WAR for AWS

    There are two key factors that must be considered before you think about conducting WAR on AWS:

    1. Architecture Complexity.
    2. Skill Level.

    We are going to look at some example cases on what combination of factors should encourage you to wage WAR, or not.

    Case 1: Highly complex architecture and expert skill set.

    If you have a highly complex architecture and an expert skill set, a hybrid approach is recommended.

    Meeting with an AWS representative at least once can be very helpful to pinpoint small, important things that are easily overlooked. For example, a focus on the business logic based infrastructure might obscure your view of a Critical Issue. 

    After the initial WAR exercise and importing the results within the AWS console, you could get away with repeating the same process internally with your highly skilled staff. Frequency of WARs depend on what you discover and the amount of resources available to you internally.

    Case 2: Highly complex architecture and novice skill set.

    When you are handling a highly complex architecture and do not have the bandwidth to understand the different pillars of the Well-Architected Framework, look for external help. Negotiating a good price with an AWS partner, is the best approach. 

    Cost concerns shouldn’t stop you from a WAR. The cost savings coming from a Well-Architected Review may justify the additional costs involved in engaging with an AWS partner consultant.

    Case 3: Less complex architecture and novice skill set.

    If you are fairly new to AWS and the complexity of your architecture is not too high, it is recommended to engage directly with AWS team. A WAR will help you understand how to handle disaster recovery, redundancy, failovers, etc. that are usually not taken into account with new teams. 

    Case 4: Less complex architecture and expert skill set.

    The only case when a do-it-yourself (DIY) approach is viable (yet optional) is when you have a low level or architectural complexity and expert level skill. 

    For a DIY WAR, you can use the AWS Well-Architected Tool, released in November of 2018, along with a user guide. Review the Well Architected Framework whitepaper and refer to the questions and best practices to conduct the review yourself.

    The Well-Architected Tool is already part of your AWS Console. It’s incredibly easy to use. There are great instructions and videos for each question. 

    Getting to know all the pillars by navigating the AWS resources is highly recommended. 

    The Process of WAR 

    The process of WAR is simple and not as tedious as you may worry. It starts with a questionnaire-based review. The review usually takes a couple of hours and is relatively painless. Whether you do it yourself, appoint an AWS partner or engage directly with the AWS team of experts, you will use the Well-Architected Tool to go through the 46 questions. At the end of the initial session, you can expect to gain a decent understanding of your current architecture and a very detailed report breaking down the Critical Issues and Need Improvement areas into actionable steps for improvement. Outside a DIY approach, you are likely to receive a detailed report identifying the gaps in all five pillars of WAR.

    Amazon is known for its fundamental principle of customer delight. This philosophy really comes alive with WAR as AWS representatives work with customers to help mitigate findings after a WAR. Often times, companies can obtain credit from AWS to fix critical issues identified during WAR. War can be done in multiple iterations, especially if several critical workloads are identified and taken into the scope of WAR.

    What Is a Critical Workload?  

    Each customer knows their business and what’s critical to their operations. That might be your customer portal processing all your orders. It might be the supply chain system driving your manufacturing processes. It might be your case management system used to ensure client work gets completed on time. The critical workload is what you identify as most critical to your operations for running, changing or growing your business.

    Various Lenses for a Stronger WAR-Time Vision

    AWS means it when they say “put on various lenses.” The WAR process is an ever-evolving process. AWS has expanded the WAR for some very specific use cases. AWS calls these “lenses”:  

    Each lens area is changing quickly and has different architecture best practices. This is a strong reason why relying exclusively on a CSP for cloud security is never a good idea. A constantly evolving threat landscape makes it critical to understand the necessity of shared responsibilities and what is at stake. 

    For the sake of understanding, let’s focus on one of the lenses: serverless.

    Serverless computing assumes the provider runs the code provided by the customer while completely taking care of the infrastructure and the environment itself. Serverless providers offer what is known as function as a service (FaaS) platforms. FaaS platforms execute code for the application logic, but remain completely stateless themselves, meaning they do not store data. AWS Lambda is the oldest and the most popular public cloud infrastructure serverless computing offering.

    Serverless lens reduces the attack surface. Because AWS takes the infrastructure concerns on itself in their entirety, there is no need to harden EC2 operating systems and configuring container. Also, because there are no data or state exposure to the data, compromise is limited. 

    What still need securing are the APIs to and from the functional computing and access control, including authentication. To secure these vulnerable areas, runtime tools—such as Wallarm’s AI-powered solutions—can enable serverless API security and apply the well-known Defense in Depth strategy.

    To augment WAR process with actionable application security steps and strong granular authentication practices, we recommend:

    1. Applying auto-configured, run-time API security for Defense in Depth.
    2. Integrating automated security testing into your build or continuous integration process.

    DAST: Dynamic Application Security Testing. DEV: Developer.

    WAF: Web Application Firewall. SEC: Security.

    FAST: Framework for Application Security Testing. OPS: Operations.

    CI/CD: Continuous Integration/Continuous Testing.

    Conclusion

    The AWS Well-Architected Framework will provide strategies to help you compare your workload against the best practices recommended in this article. It can also help you get guidance on producing stable and efficient systems, so you can focus on functional requirements and overall business.

    Start learning about WAR by downloading the AWS Well-Architected Framework whitepaper. If there is one thing you must do to best understand and operationalize your shared responsibility with your CSP, is to perform a WAR.

    — Kavya Pearlman