staging-devopsy.kinsta.cloud

Author: Bill Doerrfeld

  • How To Foster a Culture of Citizen Developers

    How To Foster a Culture of Citizen Developers

    What can leaders do to encourage a thriving environment of citizen developers in their organization?

    Over the last several months, businesses of all sizes have had to embrace rapid change, as have their workforces. When it comes to IT departments, even before the pandemic many were fielding requests to implement new technology, customize solutions to niche problems and automate specific tasks at rapid rates. Unfortunately, these increased demands coincide with an ongoing developer drought, and paired with the pandemic, have put an added strain on some already thinly stretched IT teams.

    As a result, there has been an observable rise in citizen developers being tapped to relieve some of this burden. “Citizen developer” here is used to describe any programming novice or non-developer who has been tasked with the responsibility of constructing custom applications. This person has some familiarity with programming but may not have been formally trained and, therefore, may use their own set of tools and workarounds to complete the work. If leaders don’t make an effort to create standardization, the consequence can be high variability in quality, efficiency and output.

    And it doesn’t seem to be a passing phase. I recently spoke with Dave Garrett, chief strategy and growth officer at Project Management Institute. As we look to the future, Garrett believes that citizen developers will play a critical role in helping organizations stay agile and ensuring projects move forward without delay.

    Though it won’t solve all of your pressing technical concerns, the good news is that with smart strategies, a citizen development emphasis can ease the burden on IT teams and improve output. Garrett spoke to a sea change of new techniques being developed to respond to these growing needs.

    4 Elements of Strong Citizen Developers Culture

    1. Standard Toolsets

    To start, build a solid foundation by choosing standard toolsets. Be sure all development staff is made aware of the toolsets you’ve deemed standard, clarify that adopting them is a priority and ensure that all have access. Standard approaches to using these tools should also be established and communicated, such as programming languages and stylistic standards.

    “If you have a standard toolset and approach, then you have many people who can help,” Garrett said, emphasizing that by doing so, you are building a broader base of support. Having a larger pool of employees to pull from helps an organization stay on top of the necessary tasks and creates more freedom for open collaboration. As a bonus, professional developers are freed to focus on more advanced tasks, such as machine learning and or mathematically complex programming.

    In deciding which toolsets and approaches to make standard, Garrett said, ask yourself, What will get them from A to B most quickly and efficiently? One approach to this is low-code or no-code tools. He considers such platforms transformational in empowering citizen developers to express ideas tangibly without a great deal of coding.

    2. Technical Training

    From here, ensure that all development staff, especially your citizen developers, have been technically trained in adopting the standard toolsets and approaches that have now been established. This may include offering training in low-code UIs and instilling fundamental programming concepts such as boolean logic and conditional programming such as If/Then/Else statements.

    “Set a foundation of success for learners,” he said. For example, have them build something of value during training, making it as actionable as possible for the use cases they will be handling.

    3. Discouraging Use of Shadow IT

    Once you have established toolsets and training, leadership should do whatever’s possible to enforce the established standard’s adoption and discourage the use of shadow IT—tools, applications and workarounds not approved by leadership within the company. Shadow IT, as a practice, can be messy, creating high variability and making quality-control and collaboration difficult. “You want to avoid it,” Garrett said.

    4. Good Mentorship and Governance

    Another benefit of having a standard toolset and eliminating shadow IT use is that it enables more efficient mentorship—critical for inspiring citizen developers. IT teams are advised to identify a mentor or group of mentors proficient with the standard tools to offer ongoing guidance to the team’s citizen developers.

    Quality mentorship goes hand in hand with quality governance. “Governance” here is used to mean technical admins who enforce the use of technical standards, tools and programming styles. No-code tools require access control that reflects a citizen developer’s permissions.

    Building in Hyper Agility + The Two-Pizza Rule 🍕🍕

    One way to think, Garrett said, is hyper agile. This can apply to team size, smart PM cycle lengths and brainstorming techniques.

    Team Size

    In thinking of ideal team size, ask: How can the team be optimized to work quickly and efficiently? One suggestion Garrett had was to ensure your team isn’t too large to effectively train, mentor and govern. For example, as a rule of thumb, he mentioned the old “two pizzas” rule: A team size shouldn’t require more than two pizzas to share a meal.

    Sigh. Remember things like in-person training? Pizza parties? Obviously, old meetups can’t be executed exactly to plan these days, except with some clever contactless delivery tactics, but you get the idea. A strategically sized team will create an efficient workflow and collaboration in your team dynamics.

    Cycle Length

    As projects come in, an agile cycle length, or sprint, for completing a specific set of work should be determined. What is an efficient amount of time to expect a team to turn out a project? To determine this, sprints should start with a planning meeting during which the product owner defines the work criteria. The development team determines a realistic time frame to complete the work scope. The scrum master or team manager typically makes this call.

    The lengths of agile sprints can vary—some may be two weeks, while others may be 30 days—depending on the scope of work. Most project management experts recommend you aim to keep your cycle length consistent, so teams get used to working within a set amount of time.

    Brainstorming

    Bringing attention to how your team ideates together is an excellent way to build agile collaboration. Brainstorming as a development team fosters collaboration and allows you to aggregate the talent and pull ideas together for the best output, whether you’re trying to solve a niche problem or simply join forces around how best to complete the sprint.

    Garrett recommended bringing people together in smaller groups for round-robin brainstorms and creating as you’re ideating. “Thus, iterations happen fast,” and all team members are given a chance to express their ideas in a tangible way.

    Once citizen developers see success, you can then use the excitement of building applications and solutions together to drive things forward, he said. Your anchor is a cool product that gets people excited—great for both morality and high-quality output.

    When Are Citizen Developers Appropriate?

    The question should be asked: When is it appropriate to call on citizen developers? Garrett recommended performing a suitability assessment to identify the best use cases for citizen developers. This will help the organization understand when it’s smartest to bring them in.

    The easiest way to answer this may be to consider: When isn’t it appropriate? Assigning advanced processes to citizen developers such as algorithm-heavy, mathematically complex programming or core product functionality is usually inappropriate, he said. Instead, utilize citizen developer talent for constructing internal business utilities that can be automated easily.

    There are formal suitability assessment tools that look at scores and attributes for applications to help you make this call. “However, everyone’s different,” Garrett noted. “You have your own ways of working, given context, goals and what you’re trying to accomplish.” So it may make the most sense to perform your own internal suitability assessment.

    Do the Numbers

    According to a recent PMI report, over the past five years half of organizations have recognized team members who brought innovative ideas forward, but:

    • Only 25% required dedicated time for innovative thinking and idea generation.
    • Only 19% hosted a creativity lab or hackathon facilitated by a professional.

    By contrast, their research shows that those promoting innovative practices see stronger results. Case in point:

    • 80% of organizations that encourage project leaders to expand their role have invested in at least one innovative idea in the past five years.

    The trend PMI sees on this front is that organizations want to innovate, but don’t always know how to make it happen. So, how might they push innovation forward? If you can implement a strong citizen development toolset, you can “enable innovation to bubble up,” Garrett said. The hope is this guide offers a blueprint for fostering just that.

  • Maintaining Progressive Delivery Quality With Feature Flags

    Maintaining Progressive Delivery Quality With Feature Flags

    How does Netflix know exactly what you want to watch? How do social networks ensure major software updates are smoothly deployed across millions of users? The answer, in part, lies in progressive delivery. Progressive delivery, the incremental introduction of new features, has become key to rolling out new features. By testing unproven features on a small subset of users, platforms can advance quickly while keeping rapport with the main userbase. But, where does QA fit into the progressive delivery cycle?

    As software development teams face the need to iterate rapidly, the role of QA engineers is evolving as well. QA teams are increasingly assigned to support new customer experience initiatives and meet developer consumer needs. They must do so while understanding which customer metrics to monitor as developers introduce new features.

    I recently chatted with Jeff Sing, lead software QA engineer at Optimizely, recently acquired by Episerver, to explore how feature flags could be used to maintain quality and respond to user feedback throughout a progressive delivery life cycle.

    Defining Progressive Delivery and Feature Flags

    Progressive delivery is is a software release style that emphasizes very early code pushes and rapid feedback. By testing features among small subsets of a greater user base, developers can quickly gauge what works and what doesn’t.

    Feature flags are a necessary component to make progressive delivery work. Also called feature toggles, feature flags are switches that enable developers to turn a feature off or on, helping engineering teams test unfinished features or alpha features while avoiding maintaining multiple branches. “Feature Flags are a powerful technique, allowing teams to modify system behavior without changing code,” wrote Pete Hodgson in a post on MartinFowler.com.

    Feature Flags Enable Experimentation

    Adopting feature flags for progressive delivery allows for a lot of experimentation, said Sing. For example, companies could test a new user interface adjustment on a small subset of users. If it works well, the team could further and optimize it for specific user tastes.

    “Why would you want to build something that no one wants to use? How do you know you’re building the right thing?” asked Sing.

    Iterative release strategies are nothing new—and they go by other names: canary release, A/B testing, targeted rollouts and feature gating. However, what seems unique about feature flags is the ability to optimize granularly.

    For example, if you compare a friend’s Amazon home page with your own, you will likely find the dashboard, product recommendations and overall UI vastly different. These companies are continually “running active experiments on a per-user basis,” said Sing. This enables them to personalize experiences to niche user tastes, in real-time.

    Many other companies are utilizing progressive delivery tactics. Blue Apron, for example, adopts experimentation to find and refine business value. Experimentation is core to how HelloFresh distills its customer experiences. Compass also uses progressive delivery tooling to enable feature flagging within a suite of apps serving various platforms.

    For QA teams, this means shifting right—from business testing to nano-testing at the pace of constant delivery. Thus, QA teams must have an active role—“continually test customer feedback and continually reiterate on that feature,” said Sing.

    Implementing Feature Flags: QA Shifts Right

    By adding customer feedback into the continuous delivery loop, feature flags aid incremental deployment strategies and become essential for DevOps. So how do we implement feature flags in our application development processes?

    If we’re testing a single function within a small product, an obvious idea would be to comment out or uncomment code. But, that doesn’t scale well. Developers could, instead, program a conditional variable. However, there is still more dynamic feature-toggling options. More advanced solutions may involve a toggle router and/or a UI-driven alternative.

    Sing described a system using switches written as YAML files and adopting a visual dashboard to toggle on/off features. This setup can enable a process whereby the developer checks in code and passes it to site reliability engineers (SREs) or QA managers. They can then initiate testing in production, view data from beta users in real-time and respond accordingly.

    Integrating with a CI/CD pipeline would be the next logical step. Each build could carry many potential features within each build. If a flag in the code is on, the system would execute all code and components can easily be turned off or on remotely. This way, engineers “can control how things are represented in real-time without a code deploy,” said Sing.

    Melding feature flags and progressive delivery returns extremely valuable data, Sing said. If teams can see metrics such as system behavior, bounce rate, customer NPS score and business conversions, they can better increase the quality of future deployments. “You can’t argue with hard data,” he noted.

    Benefits of Feature Flags

    Utilizing feature flags within continuous development appears to afford many benefits. In the process, QA plays a more present role in how engineering teams roll out (or roll back) new features. “QA must understand the business impact and customer story,” said Sing. “It’s not just about uptime; it’s the experience, too.”

    As you can see from the use cases above, progressive delivery with feature flags brings many benefits:

    • Quick validation: Bring new product features and proof of concepts faster to market faster by improving testing.
    • Experiment and iterate: Release incremental software versions. Experiment with new or unfinished features that consider fringe cases.
    • Development: Avoid constant merging of branches.
    • Reflect customer journey: Gather more heuristics on the customer journey to test and measure customer data.
    • Optimize per-user: Test and optimize for user tastes. “Why would you want to build something that no one wants to use?” For Sing, targeted rollouts can answer that user imperative immediately.
    • Limit blast radius: If new features introduce outages, easy togglable capabilities mean they can quickly be turned off and put back into development, thus increasing service reliability.

    Drawbacks of Feature Flags

    Feature flags introduce many efficient methods for testing new features, but they don’t come without side effects in other areas. One potential drawback of feature flags is supporting a vast number of intricately defined user scenarios.

    With each segmentation comes new optimization requirements and support must adapt to a quickly growing archive of various feature sets. Companies need advanced tooling to support the easy addition or removal of features. “You need the power to understand what’s going out and how you manage it,” Sing noted.

    A fractured ecosystem with thousands of microservices can become difficult to support continuously. Engineering teams must draw the line somewhere between endless optimization and retaining a cohesive product. Ideally, developers can reuse base components but represent them in different ways.

    Another negative side effect is public opinion. With the release of Social Dilemma and related tech industry critique, many user-facing tech networks are under harsh criticism due to the unethical use of user data to develop hyper-targeted ad campaigns. Optimization tactics that disrespect users should be frowned upon.

    This is not to mention regulations around user data and privacy. If users do not grant consent to share user data to “improve the user experience,” engineering teams won’t have the necessary metrics and tracking data required to decide which features to implement.

    While feature flags appear to help optimize business value, there are many potential “gotchas” to carefully consider before implementation, from technical logistics to service fragmentation, user ethics and legal ramifications.

    Final Thoughts

    “As with any new technology, if you don’t use it correctly, it’s almost better if you don’t use it,” said Sing. If progressive delivery isn’t managed correctly, with a QA mindset, it could come back to bite them.

    As we continually build new tech to ship faster and smarter, it’s also important to consider customer needs. “Automation is great, but a computer can’t understand what a customer really wants,” Sing noted. To avoid the technical hurdles and social dangers of hyper-personalization, QA should be customer champions that consider customer happiness.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Help Us Low-Code, You’re Our Only Hope

    Help Us Low-Code, You’re Our Only Hope

    Will low-code solve 2020’s most pressing issues?

    2020 is a challenging year. IT timelines are accelerating. The global pandemic pushes more online interaction, and digital transformations slated for years are shortening down to months or even days. As many departments face a nationwide developer shortage, companies have turned to low-code tools to keep pace.

    Naturally, interest in low-code is booming. Gartner estimates that by 2024, low-code will be behind at least 65% of application development initiatives. Today, low-code is already at the heart of many digital transformation initiatives—some vital to human life.

    I recently met with Ryan Ellis, SVP, Product Management, Platform at Salesforce. He shared how low-code is at the forefront of some very critical areas, such as COVID–19 testing, PPP loan processing, remote meal delivery, workplace safety and more. In this article, we’ll see how low-code tools are helping organizations quickly respond to these unprecedented issues.

    Low-Code Solves 5 Top Issues of 2020

    1. Meal Delivery

    Sun Basket uses low-code to scale omnichannel support rapidly

    What does digital transformation mean nowadays? It used to refer to new ways of meeting your customers online—i.e. brick and mortar business adopting eCommerce. Now, digital transformation is about providing omnichannel support for customers: phone-in, email, chat, social message and more, noted Ellis.

    Since the COVID-19 lockdown began, Sun Basket, a meal kit delivery platform, has experienced a massive increase in demand. To answer the surge in customer support, Sun Basket used a low-code platform to build a chatbot to enable users to track or edit their orders using natural language. Since investing in low-code, Sun Basket has increased the number of customer support cases handled simultaneously by 50%. This “ability to pivot to the surge in demand” is what gives low-code platforms an edge, he said.

    2. COVID-19 Testing

    UC Berkley adopts low-code to facilitate rapid COVID-19 testing

    To help underserved communities in the fight against COVID–19, researchers at UC Berkeley’s Innovative Genomics Institute recently rapidly transformed a CRISPR study lab into a pop-up COVID testing facility with the help of low-code tooling.

    The lab constructed a web portal for remote diagnosis and automated patient test scheduling. The system needed to catalog samples by barcode, synchronize the flow of information between researchers and doctors, and automatically deliver test results to patients—all while using regulatory-compliant code.

    This is one area where low-code shines: The researchers could quickly utilize pre-built components with the right data privacy measures to become operational in three weeks. “HIPPA compliance and security are built-in advantages,” said Ellis. IGI is an inspiring model for how science and technology can unite amid a global crisis.

    3. CARES Act And PPP

    Banks adopt low-code to automate loan approval processes

    With the passing of the CARES act, 70% of small U.S. businesses impacted by coronavirus quickly applied for federal loans. “Banks had to respond to a huge influx of demand and process these loans,” Ellis said. At many banks, the sheer number of applications became unmanageable.

    To handle the volume at Academy Bank, a savvy employee realized the need to automate some tedious, repetitive tasks. They used a low-code platform to build a tool for tracking application statuses and generating reports. This created an end-to-end loan approval process, which helped process more Paycheck Protection Program (PPP) applications, reduced manual repetition and improved visibility.

    Another financial service that relies heavily on low-code is nCino, a cloud-based bank operating system. nCino, which recently had one of the highest U.S. tech IPOs in recent times, built an entire automated business on top of Salesforce using a combination of some-code and cloud-first strategy.

    As banks behave more like tech companies, they need to evaluate their DevOps approach. “Leverage scale from low-code and cloud combined,” recommends Ellis. “Use the power of the cloud to push solutions to a broad base of customers all over the world.”

    4. Workplace Safety

    Low-code helps build corporate social distancing applications

    Many companies are considering their post-pandemic return to the workplace. Purpose-built low-code applications could be utilized to keep a log of fever checks and enable limited-exposure collaboration.

    Work.com, for example, offers employee health tracking, contract-tracing and workplace-planning applications to reduce risk and enforce social distancing guidelines. For example, elevator use could be optimized to avoid crowding a tight space, Ellis said.

    5. Distance Learning

    COVID has forced many schools online. Some, like Case Western, are getting creative with augmented reality HoloLens. Other schools are implementing things such as financial aid chatbots or updating their old ERP systems.

    Low-code could assist these distance learning initiatives or complement the EdTech platforms already in use. Over 100 universities worldwide already use low-code platforms within their online education curriculum.

    Digital Transformation 2.0 Is All About Automation

    Digital transformation initiatives have been brewing for years. But now, greater forces are driving immediate change—and this time, we’re all in on automation.

    The emphasis is now on optimizing and refining digital processes. “Utilizing low-code, businesses are taking processes that were very manual, error-prone, simplistic or repetitive, and automating it into a process that ensures consistency,” said Ellis.

    The above case studies demonstrate how low-code, in practice, is not only reshaping brick and mortal and traditional IT but ushering a new focus on automation and event-triggering for digital organizations, helping them adapt to turbulent times.

    The need to automate business processes pervades all companies. Ellis positively identifies an “uptick in low-code momentum these days across all customers.” For example, over two months, Salesforce noticed an increase from 160 million screen flow executions (automated workflows) to 200 million screen flows per month.

    Low-Code In Our Desperate Hour

    2020 is a challenging year. Now in the thick of a global pandemic, economies have been severely affected. However, citizen development technologies offer solutions. According to Ellis, low-code is truly “saving people—in terms of lives, businesses and livelihoods.”

    Of course, low-code platforms are no silver bullet and present a trade-off. Companies gain speed and agility, yet they move infrastructure dependencies to a third party. If not well-adopted or governed properly, low-code could enable shadow IT to proliferate. Ellis believes these concerns are negligible. “The value you bring is expertise and industry knowledge,” he said. The abstraction layer is worth it to “to move away from having to reinvent the wheel.”

    For Ellis, broader low-code adoption is on the horizon. “We’ve seen huge increases and inbound interest and use of low-code technologies. More and more people are opening up to it,” he said. Though low-code is certainly in vogue amid the pandemic, low-code tools leveraged today could be here to stay for the long-term.

  • 5 Steps to Avoid Shadow IT Around Low-Code

    5 Steps to Avoid Shadow IT Around Low-Code

    Shadow IT is far more pervasive than most CIOs think. Cisco Systems estimates that a typical firm has 15 to 22 times more cloud applications than authorized by the IT department.

    While shadow IT solves problems in the short-term for a select few, undocumented software ultimately encourages tribal thinking and siloed departments. This can stunt reusability, slow down new developer onboarding and lead to insecure points of failure—all antitheses to a DevOps culture.

    Simultaneously, new low-code tools are emerging that promise to reduce the programming burden from developers and enable citizen developers to create business applications on their own. But what happens when advanced users know better? Perhaps they’d rather code a quick function in Python or use another framework they’re more familiar with. If not properly governed, low-code platforms could easily be circumvented and lead to shadow IT.

    As many tech leaders can attest to, enforcing companywide standards can be tricky. I recently chatted with Jay Jamison of Quick Base to see what tactics organizations should take to avoid shadow IT when introducing low-code tooling. Here are five general tips CIOs can apply to reap low-code benefits while curbing shadow IT.

    1. Earn Developer Trust

    Focus on integration and open backends to earn developer respect

    Want to win the hearts of developers? Focus on integration. Many engineers don’t care about a shiny user interface and would rather interact with data models programmatically. As I’ve covered before, open API access is the secret sauce for low-code platforms.

    Choose a low-code platform that provides high-performant and secure RESTful APIs that use JSON. With open access to data models and low-level mechanics, advanced developers will feel less inclined to subvert the platform. What’s great about HTTP APIs is that they’re agnostic, so developers can interact with them from whatever language or environment they’re comfortable with.

    2. Govern and Set Permissions

    Establish access management policies with fine-grained permissions

    To avoid the emergence of shadow IT, software leaders must apply governance over data models, users and application privileges. These permissions should be fine-grained, to the field level. To do so, managers require an application lifecycle management functionality to edit these permissions. Such a governance layer would grant “tremendous power and control to IT and the business,” said Jamison.

    On low-code governance patterns, Jamison notices companies often lean toward one of two extremes:

    1. IT-centric: IT is leading the software models and only IT users can make changes.
    2. Operation-centric: IT acts as a governance body and building is pushed into business domains.

    Selecting which model to use is often based on the organizational culture and individual team member capabilities, noted Jamison.

    3. Encourage Collaboration and Knowledge-Sharing

    Build an easy path from mock-up to production

    Companies adopt low-code tools because they require something “quick and adaptable.” Yet, getting different operating teams at the same table can be difficult. Without high-quality collaboration, low-code could introduce a bottleneck.

    “Many teams must come together,” Jamison said. “How will this be productized; how will the workflow be tracked?” Companies truly require an effective collaboration model if they are ever to regularize their data models and assign access roles.

    To get everyone on the same page, Jamison recommended starting with a mock-up everyone can use as a reference: “Create an online chart to map out workflows and stitch it together in a collaboration space.” Business strategies can create detailed plans, and then builders can transform this into a prototype.

    4. Document and Reuse

    Encourage departments to document processes and expose reusable tools

    If users are sharing documentation via Excel and email, you know something’s wrong. Undocumented software is unmanageable software. Jamison reinforced the need for a “control layer” to localize documentation and encourage platform-wide governance standards.

    “Like buildings in a cityscape, some apps are more significant than others,” Jamison said. CRM applications may be entirely purpose-built for niche settings, while others, such as a team registry application, could be reused across an entire corporation. Increasing tooling reusability, he noted, requires teaching and training of documentation and change management practices.

    5. Adopt a Platform-Based View

    Standardize on a single platform and embrace a low-code culture

    The more teams use low-code, the more they think on low-code terms. As teams become more proficient in low-code, their mindset becomes: “How can low-code solve that problem?”

    By adopting a platform-based view, low-code becomes a utility to drive consistent data flows and workflows. To achieve this, it’s probably best to standardize around a single, companywide low-code platform. Otherwise, you risk inviting more unstandardized practices.

    For example, Jamison described how a large-scale manufacturer operating hundreds of plants worldwide uses a low-code platform to audit all plants’ quality in real-time. Other traditional non-IT businesses with a global footprint could similarly return a net value from consolidation on a single low-code platform.

    Will Low-Code Increase Shadow IT?

    It’s difficult to enforce any new tool, and some users will inevitably circumvent standard processes. However, by demonstrating the benefits of shared collaboration and low-code creative potential, leaders could stem shadow IT and the adverse side effects therein.

    By talking their language and saving time, low-code tools could win developer faith and encourage platform use. In review, here are some other ways to avoid shadow IT side-stepping around low-code:

    • Show some-code: Win developer’s hearts by talking on their terms and opening up the hood.
    • Govern: Use a common data model and apply fine-grained security constraints.
    • Ignite discussion: Bring groups together for open knowledge forums.
    • Unite business and IT: Enable citizen developers to design mockups and builders to execute quickly.
    • Use the platform: With more low-code use comes more creative sparks.

    Ultimately, low-code won’t replace 100% of your programming needs (especially at software-oriented companies). Low-code should be viewed as a time-saver, not a talent replacer, Jamison said. Low-code enables developers to quickly assemble simple business applications, freeing them to devote more time to core competencies or advanced processes that are far more interesting, such as building machine learning models.

    Final Thoughts on Low-Code Transformation

    There are many forces driving the current low-code revolution. Major tech hubs lack developer talent and COVID-19 has accelerated digital disruption. In this economy, requirements for business processes are changing “by the hour,” said Jamison. “The awareness around low-code is increasing because the need for automation and more digital solutions is increasing.”

    As Jamison noted, many enterprises are undergoing a “dual-track digital transformation.” Companies are investing in expensive, broad-scope cloud technologies while still digitizing many manual processes. To Jamison, low-code is now imperative to meet both needs. Thus, it should be adopted with forethought for all potential use cases (and shadowy non-uses).

  • The Rise of the Cloud Economist: The Other CFO

    The Rise of the Cloud Economist: The Other CFO

    The new Cloud Economist job title wrangles runaway cloud costs

    Have you ever forgotten about a subscription? Maybe it was that Amazon Fresh upgrade you never used, charging you monthly payments. Or, your phone carrier slyly tacked on a feature and it went unnoticed for years. All these charges may seem insignificant, but they mount up over time.

    The same is true for cloud IT tools. Many Ops engineers know all too well the surprising bills that accompany cloud infrastructure. While cloud prices may start low, they often rise unexpectedly with hidden server costs, data replication charges, escalating API fees and other fun add-on expenses.

    Conversely, remaining at a low service tier could cause latency and a loss of revenue. Drowning in a sea of hybrid trends and feeling pressure to deploy at lightning speed, it can be difficult to keep track of which cloud models actually advance business objectives.

    Some believe an entirely new role is needed to rectify the gap between cloud and business repercussions—a Cloud Financial Officer, or the Other CFO (OCFO). An OCFO could act as a Cloud Economist, a tech-savvy ambassador who both understands the financial implications of a cloud strategy and optimizes service tiers to their necessary levels.

    I recently chatted with Leon Adato, Head Geek at SolarWinds, on how businesses could better drive cloud cost optimizations. Like a determined accountant sent in to save a struggling city (h/t to Ben Wyatt in Parks and Recreation), the OCFO may be the star companies need to slash the budget and balance the cloud checkbook.

    Why Do We Need a Cloud Economist?

    According to the “Flexera 2020 State of the Cloud Report,” 74% of companies report their annual cloud spending exceeds $1.2 million each year. At 20% of companies, it’s more than $12 million. As cloud spending skyrockets, balancing these expenses becomes business-critical.

    Yet, forecasting cloud costs is tricky. Unexpected complexities often arise with the cloud, skewing initial cost projections. Maintaining cloud oversight becomes especially complex as COVID–19 accelerates more cloud adoption across the board. Budgets are shrinking, and some companies are undertaking extreme measures to remain lean.

    Simultaneously, the ones that advocate for new technology don’t always consider cost implications. “Three clicks and you’re done means a DevOps engineer in the driver’s seat may not be aware of the cost considerations,” said Adato. In recent years, SaaS companies have stressed easy onboarding and developer experience as a top priority. The staying power of developers to adopt new tools is arguably at an all-time high. But while it’s important to improve developer workflows, developers don’t necessarily have business acumen. “Finance is a lexicon of itself,” noted Adato.

    Thus, some view a Cloud Economist role as necessary for translation across divisions. “IT divisions shouldn’t be encountering sticker shock when they view their cloud infrastructure bills,” he said. “We need IT folks to be able to pay attention to cloud costs in a meaningful way.”

    What Does a Cloud Economist Do?

    A Cloud Economist is an expert that specializes in cloud-spending and cloud cost optimizations. Such a role could help teams realize the efficiency benefits of cloud-native architecture while keeping costs lean.

    This job title truly requires “hands for code and a head for money,” described Adato. He laid out three simple goals of a Cloud Economist:

    1. Increase revenue.
    2. Decrease cost.
    3. Remove risk.

    A Cloud Economist understands the technical underpinnings behind cloud tools and how they support each other within a cloud-native ecosystem. They also appreciate maintenance realities, asking tough questions such as: Will it take 200 code pushes per day to support this microservices integration pipeline? How will server costs change as bandwidth scales? Which plan is most optimized for our needs?

    Specific Cloud Economist Duties

    A Cloud Economist must manage runaway costs associated with cloud adoption. They see the bigger picture and understand the repercussions behind cloud technologies. In terms of specific duties, the role may wear many hats.

    For example, a Cloud Economist may encourage a CSP migration, such as from AWS to GCP. Or, they may foresee the implications of future feature introduction, such as limitations across geographic zones, and advise IT teams accordingly.

    An avid Cloud Economist should also interface with monitoring and testing teams. “API testing before launch can mean the difference between a $25 cloud database bill and a $30k bill,” wrote Rapid API’s Chris McCallister in a separate blog post.

    Other Cloud Economist duties could include:

    • Logging and forecasting rising cloud costs.
    • Becoming Terms of Service (ToS) experts.
    • Avoiding costly data replications.
    • Upgrading servers.
    • Discontinuing unused instances and features.
    • Ensuring elasticity of applications.
    • Database scalability.
    • Increasing CPU power or data loads.
    • Optimizing subscription plans.
    • Considering implications behind feature updates.
    • Limiting the intake of new cloud tooling.
    • Acting as an ambassador between a company and CSPs.

    Traditional IT, or information services, as it was originally called, “has been able to avoid the need to integrate with business,” said Adato. That will likely change drastically as cloud costs escalate and thousands of very small charges amount to “death from a thousand cuts.” It appears that any business size, from startup to enterprise, could benefit from more cloud expense forethought.

    Inherently, DevOps is a cultural movement, not a technical movement, Adato noted. Assigning a Cloud Economist encourages specialization and de-siloing between disciplines, freeing up DevOps engineers to work on projects that matter to them. The role of a Cloud Economist “offloads responsibility that has always been there that may have been ignored,” he said.

    Avoid Ice Town With a Cloud Accountant

    Software architects are often sold on the idea that cloud infrastructure is a cheaper alternative to on-premises. “That statement is false,” Adato said. As an organization cloud evolves out of freemium tiers, where it began cost-wise is often far from where it ends up.

    To navigate the opaque cloud, “we need someone that has fluency and familiarity with tech, understands the platform, understands how code is updated and maintained, and can right-size the cloud platform,” said Adato. Cloud-native certainly has its benefits, but if runaway cloud costs aren’t wrangled, they could equate to revenue loss.

    As author Bob Lewis wrote: “There’s no such thing as an IT project.” We don’t do technology for the sake of doing technology. Rather, we do it in service to the business. A Cloud Economist could help ensure technology answers the business call, not vice versa.

    As of now, the OCFO is mostly a theoretical title; it could materialize as an internal team member or contract hire. Regardless, such a role could advocate for the business and keep operational overhead as lean as possible.

    In general, it may require a dash of hard realism to learn how to avoid plunging the books into a debt-ridden Ice Town.

  • Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    A recent report asks the tough questions about DevSecOps adoption, and the results are surprising

    In a world of increasing development velocity, companies are placing more responsibility on developers to enact quick deployments. Naturally, security is “shifting left” as well.

    Theoretically, DevSecOps sounds great, but it opens up many questions. Who exactly is responsible for security knowledge? Are cybersecurity training measures effective? Which tools excel at decreasing risk while maintaining release fluidity? Are AppSec tools aiding or adding unneeded friction?

    A report conducted by Enterprise Strategy Group (ESG) sought to answer these pressing questions and expose trends around application development security. The study surveyed 378 IT, cybersecurity and application development professionals at organizations in North America.

    I recently met with Chris Eng, chief research officer at Veracode, and Dave Gruber, senior cybersecurity analyst at ESG, to dig deeper into the report’s findings.

    Security vs. Development

    There is still friction when attempting DevSecOps in practice. Eng recognizes a disconnect between security and development teams.

    “Most security teams lack an understanding of modern application development practices,” said Eng. Security may not realize how regularly code is pushed or understand the intricacies of tooling within a CI/CD pipeline. On the flip side, developers may not be well-versed in common container exploits and vulnerabilities.

    Organizations are pretty split when it comes to application security testing ownership. Thirty-one percent of organizations dedicate security analysts to manage application security. The development manager and security team jointly own responsibility at 29% of companies. Developer managers follow at 26%, and individual developers at 13%.

    To Eng, these figures reflect an evolution from traditional security testing to the way things are changing with faster development cycles. “Go back 10-plus years, and we had a centralized, dedicated security team responsible for managing AppSec,” described Eng.

    In modern times, security is shared or even furthered where developers themselves run tools by hand or automate security within CI/CD processes. Large companies, Eng noted, now often utilize a mix of those practices.

    Paradox: Secure Yet Vulnerable

    Seemingly, the most eye-opening part of the report was a paradox. The report found that most teams give their application security a high rating (36% gave their application security programs a 9 or 10, with a 7.92 mean). Yet, the majority say they regularly push vulnerable code (48% of respondents knowingly push vulnerable code regularly).

    Though it’s counterintuitive, organizations may knowingly push out vulnerable code for many reasons. “You’ve promised a release, customers are waiting, ” said Eng. “Revenue is waiting. What are the implications of pushing that release?” Teams may not have time to fix vulnerable code, or it may simply not be worth it.

    Publishing vulnerable code may also be a symptom of placing testing too late in the release process. “That’s why there is this trend to shift left,” added Gruber.

    Gauging DevSecOps Success

    The above findings underscore a reality of IT security: To keep pace, software providers must accept a level of risk. In fact, business success may depend on it.

    “The effectiveness of the programs isn’t necessarily measured with how many times you’ve shipped your code with no vulnerabilities,” said Gruber. “Success is that we understand the risk, we have mitigated the risk at the level we believe is right for the organization, and have the right level of control over the process.”

    Companies must weigh the cost of improper DevSecOps and mitigate imminent risk to maintain release agility.

    Application Security Tools: Finding Balance

    At modern companies with quick-release cadences, “CI integrative security tools are way more prevalent and baked into the process,” noted Eng. Yet, 26% of respondents indicate security tooling friction and ineffective tooling usage.

    Whereas InfoSec teams are usually the ones dictating policies, developers have much influence in the tooling selection. Thus, tools must appeal to the developer experience, fitting into their established workflows.

    “We have to build a habit around it,” said Eng. Frictionless tools that continually scan within an IDE, for example, can enable developers to fix an issue on the spot and foster future behaviors.

    At the same time, you must set standards and avoid governance issues. This requires control and observability. “The balance here is that you want developers to be able to integrate something tightly into their toolchain,” said Eng. “But InfoSec needs a bird’s eye view on the organization.”

    Developers Lack Knowledge to Mitigate Issues

    Though security tools may reveal vulnerabilities, they don’t always correlate with remediation. The ESG report found 29% of developers lack the knowledge to mitigate issues identified by security tools.

    There is a clear gap in the market when it comes to developer education around security. This could stem from computer science schooling, in which cybersecurity is rarely taught alongside programming languages.

    On the job, hands-on developer security training is also spotty. Thirty-five percent say that less than half of their development teams are participating in formal training. Only 15% of organizations have developers actively involved in security training.

    Just giving developers a laundry list of vulnerabilities doesn’t help mitigation. For Eng, what organizations require is habitual, recurring training with hands-on tools. “Try to simulate or provide a real-world environment for learning, identifying and patching these issues,” recommended Eng. Integrating tooling within the daily developer workflow can help with knowledge retention, because “if you don’t use it, you lose it.”

    Other best practices will only arise with a security habit. For example, most development environments ship with open defaults. “You need security training and tools to understand to restrict that appropriately,” noted Eng.

    That said, a wide variety of security tooling is already advancing this process. For example, 56% of organizations use API security vulnerability (ASV) scanning to identify and mitigate risk associated with API usage, helping secure applications as developers code dependencies.

    Final DevSecOps Thoughts

    The ESG study found 43% of participants believe DevOps integration is most important to improving AppSec programs. Yet, siloed roles and a lack of security education mean DevSecOps must still mature quite a bit to meet the security-shift-left vision.

    Other eye-opening findings included:

    • More than half of respondents (54%) use automated controls to identify and quarantine vulnerable images in their image repository.
    • The proliferation of AppSec tools on the market is a significant problem for 30% of companies.
    • AppSec spending is increasing, yet only 30% will protect more than three-quarters of their codebase 12 months from now.

    For more findings, check out the ESG Survey Report: Modern Application Development Security.

  • Low-Code: An Oasis During Developer Drought

    Low-Code: An Oasis During Developer Drought

    Key insights from Mendix’s 2020 Developer Drought Index

    You may have heard that Silicon Valley is in the midst of a developer drought. But the Valley is not alone; developer talent across the U.S. heartland has dried up. In fact, the top 10 U.S. counties with the highest developer demand per capita aren’t even in California.

    A recent report by Mendix identified new hiring hotspots and a changing U.S. map for tech talent. States in the U.S. heartland are actively seeking developer talent, though some are slow to adopt 100% remote work. In the wake of COVID–19, many are reassessing work-life opportunities, leaving densely populated cities to work and live in more rural areas.

    I recently had a great discussion with Sheryl Koenigsberg, head of global product marketing at Mendix, to make sense of the “Developer Demand Index” findings. Below we speculate on the future of developer work, and how low-code platforms may be the oasis many talent-thirsty companies seek.

    ‘Developer Demand Index’ Study

    The “Developer Demand Index” sought to identify locations where developer talent is needed the most. The process involved a geographic analysis of 2,000 of July 2020’s job ads for U.S. software developers.

    The study found high developer demand and short supply in middle America; South Dakota, Nebraska and Utah were among the top states with the lowest supply to demand.

    At a county level, the highest developer demand was in Cumberland County, New Jersey; Minnehaha County, South Dakota; and Pontotoc County, Mississippi.

    The study demonstrated how more established tech hubs—Silicon Valley and Austin, for example—have a better balance of talent demand and supply.

    “The study confirmed unpopular theories that I had,” said Koenigsberg. “Developer drought is not a Silicon Valley or coastal-only problem; smaller metros throughout the country are experiencing the same problem.”

    Conditions for a Drought

    Why do states in the nation’s heartland have a developer drought to begin with? I assumed that a lower average salary in middle America would deter developers, but Koenigsberg said the conditions are more complex.

    “I don’t necessarily see a correlation between average salary and developer drought,” she said. Rather, new tech hubs continue to form wherever larger enterprises can get tax breaks. Other regional perks could include local government startup incentives or university partnerships.

    Tech certainly has a history of revitalizing less dense areas with new hubs. Take Google’s expansion into Austin, Amazon’s takeover of Seattle’s South Lake Union neighborhood or SpaceX’s remote Starship site in Boca Chica, Texas. Naturally, these areas attract the requisite talent and encourage other companies into the fold as well.

    For example, the report speculates South Dakota state could be a new Silicon Prairie hotspot. “A vibrant tech & startup scene, local talent, and the lowest COVID–19 rates are all driving the economic surge in this state,” read the report.

    With remote work and social distancing brought on by COVID–19, technology companies are adapting and the urgency to cluster in certain locales may dissipate.

    COVID–19 and Remote Work

    Software was already eating the world. But with COVID–19, it’s eating physical reality itself.

    With COVID–19 forcing many companies 100% online, the need for new software is skyrocketing like never before. Google, Facebook and many others have enacted stay-at-home plans for most of 2021. After the crisis, remote work will be a more permanent reality for many.

    While COVID–19 benefited tech, many brick-and-mortar businesses were less prepared. We’re now seeing the frailties of old systems, described Koenigsberg, and the need to replace paper-based or manual operations with digitized versions. Consumer-facing companies that did not vigorously embrace digital transformation before COIVD–19 are now in a tight spot.

    Low-Code Waters Fill a Developer Drought

    According to Derek Roos, CEO of Mendix, “the ‘Developer Demand Index’ shows that companies need to think differently about how and where to engage skilled tech workers in 2021 and beyond. Traditional development paradigms basically fall apart when you’re dealing with mobile or remote workflows.”

    As I covered recently, COVID–19 is only one of many factors spurring a low-code revolution. By utilizing visual-based models, “citizen developers” can construct applications. This enables a business analyst, for example, to string together an internal application without jumping through the traditional IT hoops. Koenigsberg identifies other low-code benefits:

    • Hire Local: If tools are less impenetrable, companies can retrain local employees, helping recover the developer gap and negating the need to hire externally.
    • Collaboration: Low-code aids remote work, enabling pair programming where teams work on the same model simultaneously.
    • Domain Expertise: Citizen developers with niche domain knowledge can better optimize applications to their industry needs. Knowing a factory production yield, for example, can help better construct a manufacturing application.
    • Women in Tech: Koenigsberg notices significantly more female involvement at low-code themed events. Hopefully, low-code can have a balancing effect on gender participation in tech.

    Final Thoughts

    The Mendix “Developer Drought Index” revealed areas of high demand and short supply throughout the U.S. Interestingly, 92% of the job ads analyzed in the study required a specific location. Regardless, the report concludes there are compelling “opportunities for companies and individuals to decentralize talent away from established tech hubs using virtual teams and cloud technology.”

    Low-code seeks to democratize software development to keep deployments on pace with the intense demand for software. Of course, low-code is no cure-all, and Developer Drought locations will likely still seek external or offshore hiring to supplement. However, low-code may offer the respite needed during uncertain times.

  • 3 Key Issues With Hybrid Cloud Transformation

    3 Key Issues With Hybrid Cloud Transformation

    The cloud has fractured. Nowadays, it is nearly impossible to scale a cloud-agnostic digital transformation initiative. The reality is that most enterprises adopt a hybrid cloud arrangement. Whether designed strategically or throughout years of competing vendors and technology influences, hybrid cloud environments, and the problems therein, seem a mainstay for modern IT.

    Many digital transformation efforts are culminating in hybrid cloud scenarios. 451 Research recently found 72% of enterprises are already using more than one cloud vendor. As one can surmise, competing standards and inconsistencies among cloud tooling can cause headaches for developers, security teams and potentially even end users.

    3 Common Cloud Transformation Problems

    I recently met with Jeff Kukowski, CEO, and Grant Ho, CMO at CloudBolt Software, to identify issues within today’s cloud transformations. According to CloudBolt, custom coding, governance concerns and cybersecurity incompatibilities are among the top problems that hold back cloud transformation (or make it very costly). Below, we’ll see what strategies they recommend to solve these problems.

    1. Custom Coding

    In 2020, a software-defined approach seems the obvious preferred choice for most IT professionals. Yet, custom code is still a significant struggle for hybrid clouds. The Standish Group research shows 19% of projects will be canceled before they ever get completed. Further results indicate 52% of projects will cost 189% of their original estimates. Custom code decreases reusability and creates redundancy.

    2. Lack of Governance

    With many disparate cloud applications, it can be difficult to set standards. There is not much control. This free-for-all can directly impact the business. Lack of visibility into resources, a related concern, could cost a business significant expenses. Citing a recent Gartner study, ParkMyCloud estimates that companies waste $8.8 billion on idle cloud resources each year.

    3. No Role-Based Security Policies

    Gartner found that 33% of enterprise security attacks are happening from people using resources in the cloud and not necessarily putting the proper governance and security parameters in place. Without role-based access control (RBAC) and a standards-based way to apply RBAC across all your resources, hackers can more easily penetrate a hybrid cloud.

    How Hybrid Cloud Affects DevOps

    These above problems are quite broad, but they reflect a culmination of many roadblocks along the development pipeline. In terms of DevOps, juggling the ever-growing variety of hybrid cloud tools could easily stunt deployment velocity.

    Kukowski described how cloud IT faces a plethora of tooling styles. They include on-premises tooling, serverless, infrastructure as code, Terraform, Kubernetes and backup as a service. “Greater than 70% of organizations are not only multi-cloud, but they are multi-tool,” he estimated.

    Naturally, supporting nuances between them becomes tricky. Not only must you recognize governance and security inconsistencies between platforms, but you must maintain them “into Day 2,” he said.

    Solution: Policy-Based Automation

    With hybrid cloud tooling now a reality for most enterprises, managing them becomes the next logical step. Solutions primarily revolve around better automation to increase self-service capabilities. For Kukowski, the answers lie in automated governance, heightened tooling visibility and implementing enterprisewide security policy services to automate security compliance and decrease custom coding.

    One way to achieve these benefits is by utilizing a Cloud Management Platform (CMP). Gartner’s 2020 Magic Quadrant for Cloud Management Platforms includes CMPs from CloudBolt, Embotics, Flexera (formerly RightScale), HyperGrid, Morpheus Data, Scalr, and VMware with vRealize Automation Cloud plus CloudHealth. A CMP layer could help automate self-service IT, assisting engineers to do their work with governance and security capabilities in place.

    Using a CMP, companies could eliminate custom coding for things such as access control. Such increased visibility could, for example, significantly decrease AWS server cost by reducing unused deployments. A CMP can benefit CI/CD too. Home Depot, for example, uses a CMP to greatly improve efficiency, decreasing infrastructure deployment time from weeks to hours.

    “Who is authorized to perform that action, on that K8s container, local VM, or cloud machine? We need visibility into that,” Kukowski said. “What is it doing? When is it running? Who has visibility to shut it down?” He recognizes that deep industry expertise is required to abstract complexity and standardize governance across all these situations.

    Streamlining the Polymorphic Cloud

    Saturated within an overabundance of cloud tooling, it’s easy to lose sight of your enterprise’s IT policies. Without global DevSecOps standards, security for hybrid cloud becomes risky.

    Enterprises with multi-tool environments are also at risk of wasting development time and effort. “We want to make sure the market does not repeat the problems of the past,” Kukowski noted. “Why custom code the fundamentals that operate your business?”

    Instead, companies should seek to reduce redundancy and eliminate custom code for each point to point integration. However, abstracting such complexity involves porting governance standards across all environments—a challenging feat for internal teams.

    The solution could lie in utilizing an external CMP layer. Such a layer could offer a software-defined approach to eliminate custom coding, offering policy-based security controls that consider the organization’s needs.

  • APIs: The Secret Sauce for Low-Code Platforms?

    APIs: The Secret Sauce for Low-Code Platforms?

    As companies become increasingly talent-strapped, APIs are helping spur a low-code movement to help them remain competitive

    Low-code platforms have the potential to alter how software is built and delivered. By focusing on visual flows and drag-and-drop UIs, low-code platforms dramatically lower the barrier to software development.

    Yet, anyone with a toe in the no-code waters will tell you the space is full of half-promises. Can you scale an entire enterprise software architecture with zero code? Probably not. Can a low-code platform single-handedly create and expose compelling infrastructure? Maybe.

    I recently met with Jon Scolamiero, manager, architecture and governance at Mendix, a Siemens business that bills itself as a low-code alternative, to get to the bottom of the low-code phenomenon.

    Read on to discover why low-code platforms could be the next big thing. We’ll cover low-code benefits and caveats, the use of low-code in agile application delivery and how an API-first emphasis sets some low-code providers apart.

    What is Low-Code?

    Low-code platforms use drag-and-drop tools to help non-developers assemble software solutions. Instead of coding every line, integrating with databases and programming network integrations, low-code users visually construct application models with default containers that initiate the logical processes and data storage abilities they require.

    In this way, low-code is dramatically abstracted from standard software development. Examples of low-code platforms on the market include Siemen’s Mendix, Amazon’s Honeycode, Google’s AppSheet, Microsoft’s Power App and OutSystems. Among these solutions, default configurations and customization abilities vary.

    Low-Code Benefits

    With the growing need for more applications, companies turn to productivity solutions such as low-code development to quicken velocity. There are, theoretically, many other benefits to low-code or “no-code” platforms:

    • Welcomes “citizen developers” into the fold: Low-code platforms offer unprecedented usability for the less technical folks. By reducing the barrier to entry, laypeople can participate in complex application development.
    • Break silos and improve collaboration: Since non-technical roles can become more involved, low-code enables better collaboration between teams. It provides a common language for organizations.
    • Improved time to value: Some low-code platforms allow you to build, deploy and run instantly, thus dramatically reducing development time. Especially if integrated with CI/CD capabilities, using low-code platforms means a greatly decreased time-to-value.
    • Addresses the talent gap: In a world of high engineering demand but few developers, low-code development spurs continual growth in light of a limited workforce.
    • Cloud-agnostic: Low-code can grant cloud-agnostic capabilities, enabling companies to run applications on SAP cloud, Azure or “lift and shift” to other cloud vendors.
    • Platform-agnostic: Low-code platforms also offer device-agnostic capabilities, meaning the application could run native mobile code. A low-code layer could also help cater to other experiences, such as voice, chatbot or smart televisions.

    Low-code could also support digital transformation initiatives for internal, non-commercial solutions. For example, a manufacturer could leverage low-code capabilities to quickly spin up connected digital solutions to help operationalize factory production.

    Low-Code Caveats

    Though low-code suggests many positive outcomes, Scolamiero said that industrywide, there are some issues:

    • Security: Good security with low-code is possible yet complex to implement. Low-code platforms must carefully handle access management and delegate identity throughout the app ecosystem.
    • Normalizing expectations: Low-code isn’t magic. These platforms have their limits and do take time to onboard. Scolamiero encouraged having a robust training program ready and available “to teach everyone how to fish.”
    • Consulting services: Scolamiero cautioned IT leaders to beware of some solutions that taut the low-code or no-code label, yet are more akin to consulting divisions. Buying armies of service people is “not a respectful business model for a customer,” he said.
    • No universal standards: Scolamiero noted that the low-code industry has yet to unite on a data integration at scale method.

    APIs Under the Hood: The Secret Sauce

    In 2002, Amazon CEO Jeff Bezos issued a companywide mandate, which has become known informally as the “API Manifesto.” In it, he stated that “all teams will henceforth expose their data and functionality through service interfaces.”

    This API-first strategy increased internal efficiency and reusability, and eventually enabled Amazon to resell its own infrastructure, creating a whole new class of impressive revenue streams. Lyft is another excellent example of a microservices-driven product.

    Many developers now fully understand the power of wrapping everything in a web service. Yet, based on his conversations with clients, Scolamiero estimated that 1 in 6 CIOs are still unaware.

    “If they were, we would have 10 Amazons at this point, not one,” he said. “It’s really easy to wrap your head around data having value, but now it’s the infrastructure that matters.”

    An added emphasis on APIs fits into the current trend toward event-driven, message-based systems. Having the ability to expose APIs to different clouds increases API elasticity, he said.

    Keeping APIs and Low-Code Under the Hood

    Low-code and no-code solutions promise that anyone can become a developer. While the reality is a bit more complicated, with the right frameworks in place, perhaps teams can become closer to that ideal.

    Utilizing an API-first approach both for systems that comprise low-code platforms and providing the ability to expose data through APIs could give low-code platforms an edge.

    According to Scolamiero, tech leaders are still “digitalizing traditional paper processes.” They don’t often think of streamlining event-driven architecture, or how infrastructure itself could have external value.

    Regardless, if it successfully executes a business case, then it works. Perhaps business leaders don’t necessarily have to know what’s under the hood. That’s sort of the point of low-code, isn’t it?