devopsy.kinsta.cloud

Tag: IaaS

  • How to Respond to Rising Cloud Costs

    How to Respond to Rising Cloud Costs

    As organizations ascend to the cloud, their cloud expenses are floating to the same lofty heights. But are all cloud costs necessary? The answer is a resounding no — there’s a lot of waste.

    In 2020, organizations wasted $17.6 billion on idle cloud resources and cloud overspending, according to ParkMyCloud. Data egress, upgrades and subscriptions to SaaS tools also crowded the cloud invoice inbox. With digital innovation a pressing concern, cloud spend is forecasted to rise significantly in the coming years. Without the right fiscal discipline in place, companies face escalating fees.

    I recently met with Eugene Khvostov, VP of product management at Apptio, to discover how organizations can rein in cloud and SaaS spending. According to Khvostov, IT departments require increased visibility, optimization and responsibility if they are to curb the cloud checkbook. Below, we’ll see what he means and discover useful tips for reducing unnecessary expenditures. Following these general guidelines could help right-size your cloud offerings across AWS, GCP, Azure and other cloud-based tools.

    Where We Are With Cloud Costs

    The pandemic has ushered in significant growth in the cloud computing and SaaS space. We’re also seeing a multi-cloud fracturing effect, as cloud service providers like GCP and Azure reach parity with AWS offerings.

    Cloud tooling grants extraordinary flexibility, elasticity and scalability. Being able to spin up or wind down an instance on a whim has permanently altered how software architecture is built. Yet, with great cloud power, comes great responsibility. “How do I make sure I’m not wasting money in the cloud?” Khvostov asked.

    According to Khvostov, as more organizations move to hybrid and decentralized multi-cloud models, more and more questions arise: What is the total cost per service? Who is spending what? Is cloud spend actually driving growth, and, if so, how much? How are new tools being procured?

    Three Cloud Financial Management Strategies

    To address these concerns and plan for cloud spending increases, Khvostov recommended three general strategies. These three phases can be thought of as research, remediation and prevention.

    1. Access and Visibility

    “You’ve got to have access and visibility,” said Khvostov.

    First, companies require access to their spending data. In this case, large, general invoices are not granular enough. You need breakdowns by service, said Khvostov, to access more fine-grained spending habits.

    Second, you need to equate those spending habits to team usage. This requires improved visibility into your organizational structure and service usage tracking at a team-by-team level.

    2. Optimize

    Next comes optimization. Ensure cloud footprints are appropriately sized for each application, and ensure you don’t have any idle resources, Khvostov said.

    Where do you have the opportunity to optimize? Well, it could be as simple as shuttering an orphaned volume, such as an Amazon Elastic Block Store (EBS), which could persist even after an EC2 instance is terminated.

    “BS volumes tend to persist unless you select the Delete on Termination,” AWS explained. So, check your configurations. Amazon provides a way to detect this using OpsCenter.

    3. Responsibility

    Once things are optimized, you need to maintain standards. “You must ensure teams drive responsibility for spend management and optimization,” said Khvostov.

    But how do you instill an optimization mindset and empower engineers to take action? Khvostov said it’s all about demonstrating a measurable return on investment (ROI) and continuing discussions between stakeholders.

    A recent report from A Cloud Guru found that 90% of organizations plan to expand their cloud services over the next one to three years, but 44% lack a plan to upskill their workforce. Most groups have their work cut out for them if they are to assign accountability for cloud costs ownership.

    Specific Cloud Costs That Bite

    So, what are some other particular areas we should be watching? Well, arguably, the most common cost is hidden data transfer fees. Surprise ingress and egress fees can be costly — take the story of Chris Short, whose personal site was charged $2700 for an unexpected 30.6 TB data transfer.

    Watch out for other cloud costs around:

    • Services automatically launching or autoscaling.
    • Idle resources due to “orphan” instances or overprovisioning.
    • Price lock on granular commitments. You could be stuck in a savings plan on an Amazon EC2 R5 instance, which would be lost upon upgrade to R6. (Khvostov acknowledged that AWS has remedied this situation, to an extent).
    • Legacy, less-efficient code can rack up cloud costs, The Information reports.

    The Cloud Economist Role Is Trending

    To unearth these costs, some believe a brand new role is required. A cloud economist is a cloud financial manager that helps spot fees, directs further cloud optimizations and calculates overall ROI from cloud investments.

    The rise of cloud financial offers is an accelerating trend, Khvostov said, one that requires the right tools and practices within an organization to become a trusted ally. “It’s definitely a legitimate role in the sense that it’s critical to organizations,” said Khvostov. “It’s specialized enough that it requires technical and financial skills.”

    Hiring a cloud economist, or building a cloud financial center of excellence, could provide a lot of value. Yet, gauging the ROI of this role isn’t immediately obvious. Some optimizations could take time to visualize, Khvostov said. A certain change could instantly invoke 20% cost savings, but you may not register that impact for 30 days or more.

    “It’s not just about cloud infrastructure — it’s about your SaaS spend, as well,” Khvostov added. He believes companies desperately need a window into what infrastructure-as-a-service (IaaS) and automation, like Chef or Jenkins, cost, along with the time savings and dollar ROI their usage equates to — because, he said, “You can only right-size what you know.”

    Trimming Cloud Spend and Cloud Costs

    Some IT folks simply fail to understand the implications of their cloud resources. Surprisingly, a recent survey by SoftwareONE revealed that 30% don’t realize that everything in the cloud is metered. To rectify this knowledge gap, organizations could use better awareness into their cloud holdings.

    The cloud is the future, and we must prepare responsibly. Yet, having fiscal discipline in a world where every software function is commodified “as-a-service” is tricky — teams require financial visibility into their cloud holdings. To rein in costs, Khvostov recommended treating it as a continuous process: access and visualize spending data, optimize your existing cloud footprint and disseminate responsibility among teams.

    Once you have a better frame of reference, you can begin to right-size cloud, right-size SaaS and appropriately right-size the team. Eventually, with the right multi-cloud and SaaS financial management strategies, perhaps that cloud bill will start to feel a little lighter.

  • Should I Stay or Should I Go? A Cloudy Decision

    Should I Stay or Should I Go? A Cloudy Decision

    If you’ve been operating in the cloud for some time now, chances are your business has changed since you first made that move and particularly during the current climate. Has your cloud usage grown considerably — and your OpEx costs? Is that just the cost of doing business in the cloud?

    It doesn’t have to be. Here’s how you can rationalize your infrastructure and determine if there are cloud expenses you can reclaim and even if it makes sense to move some of your cloud deployments into colocation.

    The rush to the public cloud has now slowed as organizations realized that it is not a one-size-fits-all solution. The main issue is the lack of deep visibility into the performance of applications provided by the host. Our own research has recently revealed that 32% of public cloud resources are currently under-utilized, and without proper direction and guidance, this will remain the case. What is needed is real-time data and intelligent recommendations to lower costs and assure performance.

    In order to optimize cloud resources, a third-party AIOps based resource is needed. This will provide an independent and granular view of how applications are using capacity and if it is right-sized. In addition, it will monitor the performance of the applications in real-time and provide metrics and analytics to eliminate bottlenecks. The allocated capacity can also be monitored to ensure an accurate match to workload requirements via real-time performance data.

    Although the major hosts provide cost optimization tools, these are not very accurate. Analysis of billing and how it matches capacity over time — as well as in real-time — is what is needed for the cloud to remain a vital part in IT infrastructure. Armed with this information you can plan capacity purchases and discover wasted spend. By using a single platform for cloud management, you can monitor your infrastructure, plan capacity and eliminate performance risks. Performance bottlenecks can be predicted before they affect clients and SLAs with multi-conditional alerting powered by advanced anomaly detection.

    Cloud solutions are not only publicly provided by the likes of AWS and Azure. Colocation is also a strong option where your applications are managed on your behalf by a system integrator. This is increasingly becoming a stronger option for more business-critical applications. But to determine which is best for you, you need to start with the facts. 

    The cloud promises IT organizations unprecedented value in the form of business agility, faster innovation, superior scalability and, most importantly, cost savings. For many organizations, it is at the core of their IT digital transformation strategy. It is a disruptive force that requires application workload behavior knowledge, careful planning and collaboration from well-informed, trusted advisors.

    As a first step, enterprises frequently target a subset of their less critical on-premises applications for migration to the public cloud. Typically, organizations will take one of two paths to the cloud:

    1. Going Cloud Native. Rewrite your application to use resources offered by a cloud provider.
    2. Lift and Shift. Very minimal or zero code changes to the application. Largely, just replicate the application in the cloud.

    The faster time-to-production choice is to lift and shift the targeted applications to a cloud service provider’s Infrastructure as a Service (IaaS). In the lift and shift option, the advantage is a reduction in the cost incurred in the physical infrastructure such as hardware, floor space, cooling, security, etc., and the management of that infrastructure. Savings will differ depending on your unique computing resource needs, workload refactoring and business models.

    Even in its simplest form, IaaS migrations must be carefully planned requiring answers to some fundamental questions:

    1. Will my application perform as expected in a public cloud? (Application Fitness)
    2. How much will it cost to run my applications in a public cloud? (OpEx)
    3. Which cloud service provider is the best choice for my applications? (Cost and Fit)

    IT managers need answers to these questions before the actual migration is performed. As most internal IT organizations don’t have deep cloud expertise, the question is: Who can you trust to provide you with the answers and help you make better business decisions?

    As technology and the cloud stands to play an ever-increasing role throughout organizations, ensuring that you’re adopting the right type of infrastructure specifically for your business has never been more vital for continued success. Choosing a service that provides the answers to your key questions, before the actual migration takes place and prepares you with vital insights into your applications and workloads targeted for cloud migration, has to be an important part of the decision-making process.

    As organizations continue to battle the COVID-19 storm, understanding the product that will overhaul your IT infrastructure, before you fully buy into it, is going to provide the confidence and assurance you need to make that decision a little less cloudy.

  • How to Implement a Data Self-Service Program

    How to Implement a Data Self-Service Program

    Data self-service is a hot topic these days. By giving different people across an organization–marketers, technologists, business leaders, etc.–access to available data and analytics tools, you empower business users and decision makers to do their jobs effectively. But data self-service is still a work in progress at most organizations.

    According to a recent survey by IDG Research, more than half of the respondents’ lines of business rely on IT or data teams to build and set up BI and analytics dashboards, versus handling these tasks themselves. The point being, at most companies, employees do not have direct access to data or to the tools that help them analyze their data. For many businesses, data self-service is the next milestone in achieving rapid time-to-insight and real-time business agility.

    Whether giving increased data access to new users or helping traditional data users achieve more advanced analytics tasks, the goal is the same: more people with the ability to quickly get the information they need, without submitting a ticket or waiting in a backlog. However, moving to a more democratized data and analytics system takes strategy and planning.

    Here are six steps that can help you organize your data self-service initiatives.

    Move Data to the Cloud 

    Any data self-service initiative should start with seriously considering moving your data from an on-prem data warehouse to the cloud, or expanding your cloud presence if you’re already there. Many obstacles to achieving data self-service are related to infrastructure and the inability to use data quickly and in a cost-effective way. On-prem data architectures often come up short when trying to handle the sheer volume and complexity of data we see today, especially within a practical budget. 

    Build a Data and Analytics Strategy

    Before your organization moves forward with a data self-service initiative, there are several important questions you should ask to help develop a comprehensive plan that is more likely to succeed and benefit your end user:

    • Where is your organization now, and where is it going?
    • What does data self-service really mean to your organization?
    • What about security and data governance?
    • What are the blockers you might face?

    Choose Where You Will Put Your Data

    In order to facilitate data self-service, you need to break down silos between data sources and bring data into a centralized location. If that location is the cloud, there are a few choices of how that will look. In moving data to the cloud, you will need to focus on storage, data acquisition, preparation and transformation. 

    In determining where and how your data will reside in the cloud, there are many factors that come into play:

    • Will a cloud data warehouse or a data lake best suit your needs? Sometimes compliance or regulatory requirements will guide or dictate your choice.
    • How important is familiarity? For example, Amazon Redshift is based on PostgreSQL 8.0.2. A company operating an on-premises PostgreSQL data warehouse may be more comfortable moving to Amazon Redshift, since they share many aspects due to common ancestry.
    • What cloud platform/vendor services do you already use? Choosing a cloud platform related to your existing services may make it easier to trust, land and expand. Sometimes a vendor offers a clear differentiator, which in itself could be a winner. For example, if your company needs to share data with multiple third parties in a safe and secure manner, Snowflake’s data sharing feature may appeal to you.  

    When bringing data into the cloud, you have three main choices of cloud architectures to choose from: 

    • Platform as a service (PaaS) is a managed service that sits inside a cloud infrastructure that gives you scalability and also lets you retain some control. Examples include certain cloud data warehouses or an Amazon S3 bucket. 
    • Infrastructure as a service (IaaS) is a bare-bones cloud infrastructure from a cloud provider–for example, AWS, Google Cloud or Microsoft Azure. It allows you to set up your own data infrastructure in the cloud to suit your needs. It offers the most control, but it can also be a complex choice.
    • Software as a Service (SaaS) is an end-to-end managed service with little or no maintenance or overhead that lets you focus on business needs and not worry about maintaining a tech stack. But, you have the least amount of control over factors such as security and how data is stored.

    Choose Your BI and Analytics Tools

    After choosing the platform that will hold your data, consider your BI and analytics tools. As with the data platform, analytics infrastructures and tools are structured in different ways, depending on IaaS, PaaS and SaaS.

    Depending on the choices you make, you may be able to continue to use some or all of your existing ETL/reporting/analytics tools. But moving to the cloud allows you to explore newer technologies and products that align better with your data analytics needs and your future strategies.

    PaaS: Sometimes, on-prem services can be replaced with equivalent or similar PaaS cloud offerings. For example, if you move to a CDW such as Amazon Redshift, Snowflake or Google BigQuery, you may be able to load a CDW database driver into your reporting platform and continue to use your existing investments. Or, you could have an ELT process that loads your file directly into a table in your CDW.

    IaaS: Within an IaaS, you could move your existing analytics infrastructure into the cloud. End-users may see improved performance due to changes in topology as well as any infrastructure-related upgrades that were carried out as part of this move.

    SaaS: Some SaaS offerings come with their own visualization tools. Like PaaS, depending on your choice, you may be able to use existing tools or explore alternatives.

    Implement and Train

    Once you select your cloud data and analytics platforms, comes the equally important step of implementing your solution and getting your team up to speed.

    Before wide-scale implementation, you should embark on a POC to try the tools and determine whether they meet your requirements. Many companies with in-house technical teams tend to carry out the POC themselves. This involves researching the technologies, learning to use them and building a minimum viable product

    Many users in your organization will have limited or no experience with running their own analytics and creating their own data visualizations. Even if you think users have experience and will quickly get up to speed, training on new tools and processes benefits everyone.

    Build a Support Structure

    Every self-service initiative needs a well defined support structure and every user needs a clear path to get help if needed. These are the two types of support:

    • Support for products and tools. Most vendors have robust support offerings available for a subscription. Most noteworthy and popular open source products tend to have active user-forums or paid support. If you have a technical partner, they may also step in to fill any gaps.
    • Business process support. It’s nearly impossible to train an end-user for every eventuality or requirement they may encounter. For example, a user may need information that is not available in their daily dashboard. To create an ad-hoc report, they need to understand the underlying data model to be able to make effective use of it. 

    Establishing a self-service data analytics platform is a multi-step process, especially if you need to modernize your data architecture to do it. Remember to take the process step by step: use the right tools to get data into the cloud and ready for analytics; lean on the expertise of your IT and data teams and your partners; and choose ELT, analytics and visualization tools that are graphical and intuitive for end users. If you follow the steps and keep these things in mind, you will be on your way to making data accessible to every person in your organization who needs it.

  • Castles in the Cloud: How to Take Your Business Kingdom Off-Prem with Confidence

    Castles in the Cloud: How to Take Your Business Kingdom Off-Prem with Confidence

    Cloud transformation requires migrating all or part of an organization’s virtual assets off-premises, typically to a public cloud.  This enables greater efficiency and cost savings, among other benefits, but it brings heightened risk as well. At the same time, many organizations moving to the cloud don’t fully understand the implications in terms of security. Consequently, successful cloud migration requires a shift in mindset.

    A Medieval Metaphor for Cloud Infrastructure

    Think of your organization as a kingdom surrounded and protected by a castle. Traditionally, this castle would be outfitted with defensive layers designed to protect the residents, the royal family and the possessions within. Protection of the castle is straightforward. A moat surrounds the castle with drop bridges in and out at strategic points (firewalls).

    In addition, guards are stationed at each entry point, conducting a thorough inspection of the people, carts and the content that they carry both in and out of the castle (IDS/IPS). The guards also check credentials at the gates and within the castle to ensure patrons are cleared for access and use of rooms and resources (IAM). The perimeter and interior walls are continuously checked for weaknesses that could introduce potential blind spots that are unguarded (vulnerability management).

    The castle has a variety of rooms, each with its own function, content and worth. Each door has a lock (AV). Within each room and the correlative hallways exist guards who check credentials, monitor the people who enter and the contents they carry, etc. (behavioral detection and endpoints). In addition, multiple other measures are in place that bolster prevention, detection and response capabilities (DLP, deception, etc.). Information from all of these sources is noted in a central location by a scribe. Guards analyze the information, looking for additional indicators of potential threats to the kingdom (SIEM) and respond accordingly.

    Comprehensively, protection of the kingdom requires an overall model and policies that accounts for new threats and tactics from rival kingdoms and thieves. Architecture of security measures are continuously updated and adaptable. In the event of an incident, the guards have designed and exercised a plan to respond. 

    Understanding the Three Different Models of Cloud 

    Clearly, this is a basic metaphor for the on-prem approach. Moving to the cloud introduces a new level of complexity to protection spread across three different models: Infrastructure as a service (IaaS), Platform as a service (PaaS) or Software as a service (SaaS).

    In the context of our castle analogy, let’s assume the castle has reached productive capacity. Neighboring rivals are creating competitive pressures, offering residents (who pay taxes) the possibility of a better life if they relocate. To keep residents happy, productivity requires expansion beyond castle walls. As production expands, neighboring kingdoms offer different models to achieve productivity. However, each model presents different levels of shared responsibility in protection (referred to as the Shared Responsibility Model).

    • IaaS: In this model, the on-premises kingdom (kingdom A) decides to expand all operations to a neighboring castle (kingdom B). The castle itself and the moats are all controlled and provided by kingdom B. However, the infrastructure, moats, hallways, rooms, access lists, monitoring of activity and protection and usage of its contents are the responsibility of kingdom A.
    • SaaS: Kingdom A decides to have blacksmithing conducted in a neighboring castle (kingdom B). The castle itself, the moats, infrastructure, hallways and blacksmithing room are all protected by kingdom B for a charge. Kingdom B’s responsibility is to control access to the room, but maintaining who’s on the access list to the room and the protection of its contents and usage are the responsibility of kingdom A.
    • PaaS: Kingdom A decides to house and build military operations in a neighboring castle (kingdom B). Kingdom B is responsible for the basic controls, but the configuration and monitoring remain the responsibility of Kingdom A.

    With this transformation, Kingdom A faces a more complex security landscape. Innovation and efficiency are critical to meeting the growing and changing demands of their kingdom, but not without additional risks. New operating models bring new risks and potential vulnerabilities to their system(s). Methodologies and processes used to secure their own kingdom do not necessarily work or apply to protecting their new partner kingdoms. Additionally, people–and experience–that understand these new complexities are harder to come by while the thieves and rival kingdoms discover vulnerabilities and weaknesses and begin to exploit and steal valuables that put the entire kingdom and its residents at risk.

    Protecting Your Castle in the Cloud Takes a Deep Understanding

    Moving to the cloud is almost inevitable at this point, and it carries so much potential to accelerate business outcomes. It takes a different mindset to secure it than what we are used to as an industry–the landscape has been changed from a security perspective. By fully studying and understanding the differences, organizations can continue rapid and secure adoption of the cloud, while reaping the benefits that it promises to bring.

    — Sean Blenkhorn

  • Infrastructure as Code and Six Key Automation Concepts

    Infrastructure as Code and Six Key Automation Concepts

    This summer, I walked into an Infrastructure as Code (IaC) flame war because I was blissfully unaware of just how broadly IaC had been reinterpreted. Reviewing the comments, it’s clear that thinking has evolved since Kief Morris’ 2016 Infrastructure as Code tomb. So, after strapping on my asbestos suit, I decided to dig into what is creating such a wide range of opinions and see if I can share some 2019 insights.

    Why does IaC provoke such passion? The reason is simple: As an industry, we aspire to something that delivers on our collective vision of fully-automated, self-governing infrastructure. In the 00s we called it autonomic computing, then software defined data center (SDDC) and, now, IaC. Sadly, IaC is not it—or, more specifically, it’s not it alone.

    The actual definition of IaC is way smaller than what people want it to be.

    My take-away from IaC discussions is they are built around six key automation themes. Let’s take a few minutes to examine each of the themes. Then we’ll have a basis for answering “If that’s not IaC, then what is it?”

    Programmatic Configuration (IaC)

    Programmatic configuration captures the idea that we can define our infrastructure in a machine readable format. For example, you describe a planned cluster build in YAML to execution by a tool such as Terraform that requests the resources from your dynamic infrastructure and, hopefully, tracks that resource descriptors you get back from that request. Basically, it’s just your IaaS input format.

    Dynamic Infrastructure (or IaaS)

    It describes a system that allows operators to change the resource allocations via an API. It’s a critical part of the discussion because there must be a dependable way to pragmatically change the infrastructure. Some would consider this cloud; however, we should not assumes either managed services or VMs because dynamic infrastructure is much broader.

    Desired State (or State Reconciler)

    Desired state actively compares dynamic infrastructure to programmatic manifest and makes automatic adjustments to keep them synchronized. Typically, the idea of maintaining state is separated from configuring systems. Kubernetes and other Autoscaling cluster managers perform this role.

    Deployment from Source Control (or Immutability)

    It implies that all of the configuration components of the system can be stored as versioned artifacts and deployed from source. A Dockerfile that builds a container is a good example of an immutable process and the generated artifact. The repeatability offered by deploying from source control is transformative compared to past generations of operations that relied on either manual or scripted changes to production systems. Immutability is not IaC: We are focused on an generated deployment artifact rather than managing the infrastructure.

    Composable (or Modular) Automation

    It allows us to manage complex structures through layers of abstraction. In concept, composability is as simple as using platform plugin to script against an API.

    CI/CD Pipeline

    CI/CD pipeline is the glue that pulls all these pieces together to create a resilient environment by continuously adjusting the system components based on the operators’ IaC descriptions. The pipeline relies on having dynamic infrastructure managed to desired state as a target; however, it adds the critical concepts of staged changes over time to the system. Since we need to create systems that can adapt and improve over time, the CI/CD pipeline provides mechanism for controlled implementation change over time.

    Together, these six concepts reflect an integrated new way to think about the infrastructure that is beyond IaC. They allow us to maintain and control our systems over time in a way that is resilient and automatic. More importantly, they bring complex infrastructure problems back into terms that people can comprehend by creating more deterministic and predictable chains of change. That allows us to keep our hands out of the infrastructure and our minds focused on what we are delivering: a continuously integrated data center.

    Since all six concepts are interdependent, continuously integrated data center (CI DC) completely captures our aspirations for IaC. The term intuitively builds from source code into a fully operational infrastructure. More importantly, CI DC demands that we acknowledge the ongoing maintenance required. For that reason, I’ve embraced CI DC to replace IaC.

    Does the term work for you? How do you see IaC or CI DC being delivered in 2020? I’d like to hear your thoughts.

    — Rob Hirschfeld

  • Why Salesforce?

    Why Salesforce?

    Over the past 20 years, Salesforce has become the fastest growing enterprise software platform, and a market leader in sales, service, marketing, integration and custom application development among other areas. Although there are many reasons why a company might adopt or consider using Salesforce, the overriding value proposition is that it provides tons of capabilities out of the box, releases new capabilities at an ambitious pace and allows for virtually endless customization and innovation.

    Unlike with traditional platforms, there’s no need to manage infrastructure for computing, data, network or security, and no need to invest in generic system administration that adds no value for the organization. Add to this the accessible and supportive community and learning culture based around Salesforce’s Trailhead, which enables rapid onboarding and skill development, and it’s easy to see the attraction of this platform.

    Salesforce’s mantra throughout the 2000’s was “Clicks not Code,” and their logo was the “No Software” image which became embodied as SaaSy, Salesforce’s first mascot. You could be a declarative developer using clicks alone and build a data model, business process automation and user interface using drag-and-drop interfaces. This opened the door to an entire new job specialization: Salesforce admins and app builders—citizen developers who were empowered to directly customize the platform to meet their company’s needs.

    As Salesforce grew, they recognized the need to enable custom coding on their platform and launched Apex Triggers, followed by Apex Classes and Visualforce in 2008. Admins continued to configure rich business capabilities, while low-code developers and professional developers were empowered to create customizations beyond the scope of what could be built declaratively. Initially, the code developed on Salesforce was rudimentary: a few hundred lines here and there to accommodate unusual calculations and data processing. But gradually, companies began to accumulate tens of thousands of lines of custom code, especially as legacy applications were migrated from other systems. Needless to say, the “No Software” motto no longer strictly applies.

    In the decade since the launch of Apex, 150,000 companies have adopted Salesforce and moved a staggering number of legacy systems onto Salesforce—which now processes billions of transactions per day. Many of these transactions are part of the core CRM and customer service applications, but a huge number relate to custom applications, making Salesforce one of the largest Platform as a Service (PaaS) providers.

    How is DevOps Different for Salesforce?

    As mentioned before, Salesforce provides both SaaS (Software as a Service) and a PaaS (Platform as a Service). By contrast, much of the focus elsewhere in the DevOps world is in moving from on-premise infrastructure to using IaaS (Infrastructure as a Service). This diagram shows an illustration of the differences between these four modes, and how they represent progressive simplifications of what companies themselves have to manage.

    Figure 1: On-premise systems require you to manage all of the resources yourself. IaaS, PaaS and SaaS delegate progressively.

    Managing the Salesforce development lifecycle requires a unique skill set and approach compared to most other platforms. You can say the DevOps movement was jointly realized by both developers (working in traditional languages such as Java) and system admins or operators (working on traditional infrastructure such as servers and databases). There are thus a vast range of well-established tools and techniques in the DevOps world for developing and deploying code, and for managing and updating infrastructure. Unfortunately, almost none of them can directly be used for Salesforce.

    To illustrate this, let’s look at how teams would manage infrastructure using AWS, or deploy an application onto Heroku (a PaaS product also owned by Salesforce). Every aspect of AWS infrastructure can be represented using JSON configuration. JSON can be used to define which AWS services are used, which data centers they are running in and how they’re configured. The AWS CLI (command-line interface) can be used in a continuous integration tool such as GitLab CI to automatically deploy updates to AWS infrastructure every time the JSON configuration changes.

    Similarly, Heroku provides a platform to deploy custom application code (in Java, PHP, Ruby, etc.) and to specify which services (such as Postgres databases) are needed to support that application. The Heroku CLI can be used to automatically update the application whenever the codebase changes. Heroku also provides a tool called Pipelines that allows you to visualize and manage the entire development lifecycle without requiring a third party CI tool.

    AWS’s infrastructure as code approach is a delight for sysadmins, since it allows them to track changes and automate updates. Similarly, Heroku removes the vast majority of the setup and dependencies that developers would need to deploy their applications. Heroku provides a true PaaS that is ready to receive custom-coded applications built in a traditional way: from the ground up.

    Although we can say Salesforce’s Lightning Platform is a PaaS, it actually works extremely different from true PaaS systems such as Heroku. The Lightning Platform allows you to write custom server-side or client-side code, but that code can only run on Salesforce. Although it allows you to define custom database tables and fields, that schema cannot be loaded into any database other than Salesforce’s. These customizations are effectively just changes to the configuration of one Salesforce instance. It’s therefore more accurate to say every customization you can make to Salesforce is basically a Salesforce configuration change.

    Salesforce is actually just a big application that happens to allow for infinite customization. But this means the tools used for managing other IaaS and PaaS products cannot be used to customize Salesforce. Fortunately however, the release of Salesforce DX means the techniques and principles used with other technologies can now be ported over to Salesforce. That is the focus of the book Mastering Salesforce DevOps that I’ve recently released.

    DevOps in the Salesforce World

    Moving from on-premises CRM software to Salesforce removes the need for servers and manual software upgrades. Consolidating customer support and online community management onto the CRM platform removes the need to integrate sales, support and community applications. Migrating legacy applications onto the Salesforce platform allows those applications to share data and processes with the rest of the business.

    Because moving to the cloud dramatically simplifies many of the challenges in delivering IT functionality, many Salesforce customers have been able to innovate quickly without having DevOps practices in place. But even without the hassle of managing servers and building software from scratch, the inevitable growth of complexity eventually causes companies to struggle with issues such as organizations getting out of sync and delays in deploying functionality.

    Salesforce solves so many IT headaches, it’s almost easy to overlook the fact that it’s created some new ones.

    Salesforce has unleashed the ability for companies to focus on their core competencies, instead of struggling to provide basic IT services. Salesforce admins and developers are empowered to spend their time directly creating business value. But with multiple Salesforce admins and developers working at companies year after year, more and more Salesforce customers are finding themselves drowning in all of that business value.

    If you have tens of thousands of components, each providing business value, but no systematic way of tracking, managing or deploying them, you now have a new form of business pain and chaos. Far too much of a good thing.

    What is Salesforce DX?

    Salesforce DX (Development eXperience) is an initiative begun by Salesforce in 2016 and launched publicly at Dreamforce 2017. The goal of the initiative is to re-envision the development experience on Salesforce with a focus on how to empower their development community with the tools and processes needed to develop safely and effectively.

    Salesforce DX is a very broad initiative, including several main teams at Salesforce focused on environment management, custom coding, developer tooling, APIs and more. Although the Salesforce DX teams tackle very diverse needs, their main focus (at least initially) is to improve the developer tooling and development lifecycle.

    The tools and capabilities included in Salesforce DX are made available for free to all Salesforce customers. In that sense, Salesforce DX is an important complement to Trailhead, Salesforce’s free, self-paced, gamified, interactive learning platform. Trailhead is also a major investment for the corporation. Together these are intended to support the growth of skilled Salesforce professionals and to make it easier for those workers to build and innovate on the platform. These multi-year strategic initiatives help ensure that talent shortages and worker inefficiency will not be the limiting factor on the company’s aggressive 30% annual growth.

    Summary

    Salesforce is an extremely powerful and versatile platform. But it’s unique in many ways and it hasn’t been easy for professional developers to adapt their tools and techniques to working on this platform.

    Salesforce DX is a major strategic initiative to ensure that industry best practices such as DevOps and modular architecture are possible on the platform. But making something possible doesn’t mean the process is straightforward. It’s still early days for most teams working to enable DevOps for Salesforce. Fortunately, there is an enormous amount of research and experience that can be borrowed from the broader IT industry. Combining a flexible, powerful platform like Salesforce with the speed and reliability of DevOps processes can open up entirely new levels of efficiency and effectiveness for teams.

    — Andrew Davis

  • Out of Date: Cloud Anti-Trends of 2019

    Out of Date: Cloud Anti-Trends of 2019

    Let’s talk about 2019 cloud tech anti-trends. A lot of those anti-trends are nothing but cloud myths, which are still widely spread and talked about.

    In this article, we’ll take a look at some anti-trends and try to understand where’s the myth part in them.

    Private Cloud Is Not Popular Anymore

    According to the IDC research organization, by 2021, companies from around the world will spend more than half a billion dollars on cloud tech. This is two times more than in 2016. At the same time, there is a clear tendency: The public cloud workloads are growing, while the situation is exactly opposite for the private cloud. Cisco said, after three years 73% of the company’s applications will move to the public cloud, while just a year ago this figure was around 50%.

    Such a shift is partly caused by cloud providers, who offer users of public clouds more and more features that simplify the development of services. For example, tools that allow creating machine learning models, manage software deployment processes and analyze logs.

    That’s why many felt the active development of a public cloud meant the final decline of the private cloud niche. During his speech at a conference last year, Anthony Lai, senior vice president of the cloud-based division of NetApp said private clouds would “die out.”

    I wouldn’t expect the private cloud to disappear completely. The statement that it will cease to exist is only partly true. The private cloud may disappear as an independent unit, but it will remain part of the hybrid IT infrastructure.

    As noted in Gartner, 72% of companies in the world use a hybrid strategy. And it is expected this figure will grow. According to analysts from Market Research, the market for cloud object storage systems will reach six billion dollars by 2023. This will definitely spur further development of the hybrid IT infrastructure.

    One reason to use private clouds is predictable business processes.

    Yes, the public cloud offers flexible scaling. The company does not have to urgently buy new hardware if the load on the services has increased dramatically (for example, the application became a success and tons of new users came in). In this case, you can simply rent additional computing power. But if the load can be predicted (say, it is static) a private cloud is often enough.

    Also, a private cloud is often used to create object storage. Sure, object storage services are also available in the public cloud and a number of companies use them. Just a couple of years ago, Netflix migrated its entire infrastructure to the public cloud.

    However, not all companies need to build a distributed infrastructure as Netflix did. There are cases when companies have object storage in a private cloud because it already has an appropriate low-cost automated infrastructure. CERN is one of them. All the data generated by the Large Hadron Collider is stored in a private cloud.

    The IT-Infrastructure Market Is Oversaturated with Specialists

    Today, companies are actively abandoning their own infrastructure in favor of cloud solutions. That is why the need for in-house specialists engaged in its maintenance, gradually disappears. The IaaS provider takes on many issues related to the management and administration of the infrastructure, and the specialists need only ensure that everything is set up correctly.

    That is also why companies often abandon their own IT departments. At first glance, it seems this will gradually lead to instability in the labor market. Experts in the field of IT infrastructure, system administrators and data center operators will have to compete fiercely for the remaining jobs. But will they really have to?

    This does not mean such specialists have become completely unnecessary. In reality, in-house specialists simply change the focus of their activities. Most of the IT infrastructure administration tasks are now on IaaS and IaaS providers are now the ones who need and are actively fighting for such specialists.

    Even when you do use third-party solution, that is what happens sometimes:

    When customers start using intermix.io for the first time, they can see the set-up and configuration of their Amazon Redshift cluster in the context of their queries and workflows.

    At that point, customers experience one common reaction: Knowing what we know now, how would we set up our Redshift cluster had we do it all over again?

    The answer is not that straightforward.

    However, sometimes it happens that migration to the cloud stimulates the company to strengthen and develop the IT department more, attracting new cloud employees. These people study the cloud ecosystem, analyze the trends and evaluate how the transfer of an application to the cloud will affect the company’s work. If the company is already working with the cloud, then cloud specialists are also exploring new features of the current platform and exploring services that will benefit a business in the future.

    Clouds Don’t Hold New Technologies

    Four years ago, IBM listed seven cloud technologies to help businesses. The list includes IaaS/PaaS, private/hybrid cloud, test and application development environments, big data processing and disaster recovery solutions, along with data storage and backup systems.

    These technologies served as a standard technology stack for a long time. It was all developed with the efforts of IaaS providers. Therefore, there was an opinion that the cloud ecosystem was finally formed and no other use cases will be foreseen in the near future.

    New Directions Still Appear: The blockchain technology was born in 2008, gained worldwide popularity 8 years later and came to the cloud about a year ago. Based on the virtual infrastructure, a new direction has started to develop: Blockchain-as-a-Service (BaaS). In this case, the client receives a virtual environment prepared for working with blockchain technology. Users can create their own applications on the blockchain (for example, for processing financial transactions) and run them in a secure virtual environment.

    Quantum Computers: the most recent, fresh cloud trend. The quantum machine uses qubits instead of bits we are used to. Unlike bits, qubits can take the value of zero and one at the same time. Thus, a quantum machine can be in several states at once. The more qubits a quantum computer has, the faster it performs the tasks assigned to it. Imagine how much faster it can brute-force passwords or simulate chemical reactions.

    Quantum computers already have practical applications. IBM has recently opened access to its 20-qubit developments via the IBM Q cloud platform. And this year, Alibaba partnered with the Chinese Academy of Sciences to deploy an 11-qubit quantum device in the cloud. Quantum Computing as-a-service (QCaaS) opened the way for experiments on the infrastructure of providers and proved the cloud industry can adapt to the emergence of new technologies.

    Another Trend Is Fogging or Fog Computing: IT-industry experts are trying to solve the problem of delay in transferring data to the cloud. In the case of fogging, server components are not located in the centralized data center, but on the periphery, close to the end-user devices.

    In such an architecture, a main, large cloud still remains but has additional networking and computing layers: cloud, fog, edge. The Cloud (cloud layer, primary) solves expensive tasks for periphery machines (edge layer, end-user): data analysis, system logging, etc. The fog layer does local calculations in real-time to generate reports and send them to the central hub. This architecture improves the performance of the entire infrastructure by significantly (up to 10 times) reducing the delay in data exchange.

    To Sum It Up on Cloud Myth-Busting

    So, as with everything, rushing into extremes doesn’t help. That’s what we figured out:

    1. Even though public cloud seems to be a mainstream option, private cloud infrastructure still makes sense for certain use cases.
    2. Most of the IT infrastructure administration tasks are now on IaaS and IaaS providers are now the ones who need and are actively fighting for Engineers i.e. market is more than far away from being oversaturated with specialists.
    3. Clouds don’t hold new technologies. Did anyone really believe this one anyway?

    — Dmitrii Borodin

  • How DevOps Replaces the BYOD Mindset

    How DevOps Replaces the BYOD Mindset

    The impasse is clear: users often have no formal way to effectively communicate to IT departments how certain devices and apps are useful for work and should be allowed to connect to the enterprise’s network. Since the debut of smart phones well over a decade ago, so-called bring-your-own-device (BYOD) policies as a potential solution have served as a solution, but have also fallen short for reasons we’ll discuss below. The idea behind BYOD is to allow users to connect their devices in limited circumstances and often without full access to the network.

    BYOD also predates DevOps and serves as one of many precursors for IT and security working more closely with other teams within the organization. This mindset of collaboration that BYOD fosters, of course, is essential to DevOps, said Holger Mueller, an analyst for Constellation Research.

    “The tension between the business and IT really is about scaling an organization’s operations in a way that is both flexible and business-focused,” Mueller said. “Compromise really matters.”

    However, DevOps, in part, can remove the need for BYOD and even replace it from IT jargon. BYOD first came about when IT, operating in isolated silos, struggled with accommodating users who used their own devices for work and, even more worrisome, often connected their devices to the network without permission. This worry is eliminated with DevOps when business, IT operations, QA, InfoSec and development teams, in the spirit of fostering collaboration across the enterprise, decide together what devices and apps are adopted, and then lay the security groundwork.

    “With the advent of more agile and distributed infrastructures, DevOps teams don’t have a walled-garden assumption anymore, which makes BYOD less of a problem in general,” said Siri Oaklander, advanced technologies principal for CloudPassage. “When BYOD started, the concern was these devices represented an unknown inside the corporate walled garden, and now we are not depending on the walled garden nearly as much for security.”

    New Mindset

    Enabling users to bring new devices and apps into the network certainly falls under the culture part of DevOps. Someone in DevOps who is a business team leader might suggest a very useful app or platform the IT department, the developers, and InfoSec readily review and test because it makes good business sense. Again, this type of interdepartmental collaboration is difficult without DevOps.

    For organizations without DevOps, suggested changes from users requesting the IT department accommodate new devices and apps, even when BYOD policies are in place, are often met with hostility, since it means more work with little perceived direct gain for an isolated IT department. Those working in IT, in this context, thus have little motivation to do the legwork to make room for new devices to manage. DevOps, of course, helps to change this mindset.

    “DevOps-style security  completely changes the boundaries and gateways, eliminating a lot of the concerns associated with BYOD,” Oaklander said. “It’s not so much that DevOps directly addresses BYOD as that the security model used in DevOps is far less vulnerable to having unmanaged devices inside the network.”

    Bring-Your-Own-IaaS

    BYOD came into play before the emergence of massive cloud deployments and the monumental shift many organizations have made to the cloud. Then, operations were often exclusively tied to the data center. Smart phones and other devices, once behind the firewall, were connected to the network that ran on on-premises servers. These servers, as well as virtual machines, were the core parts of the business and often mission-critical, noted Ed Smith, product marketing principal, for CloudPassage.

    “Now DevOps teams no longer have to rely on IT for servers either, they simply go to AWS with their credit card and bring their own infrastructure as a service,” he said. “The similar challenges apply here as they did with BYOD: How does the company control cost and risk without slowing down innovation? And there’s more at stake here because these are back-end servers used by many people as opposed to a device with a single user. BYOD happened because business users demanded it to be agile and competitive, and I think we’re seeing the same thing with what may be called ‘BYOIaaS.’”

    DevOps should thus be ready to take advantage of new cloud solutions, as well as cloud-exclusive applications, in ways BYOD would never have allowed.

    — B. Cameron Gain

  • With a Multicloud Infrastructure, Control is Key

    With a Multicloud Infrastructure, Control is Key

    Ask any developer or DevOps manager about their first experiences with the public cloud and it’s likely they’ll happily share some memories of quickly provisioning some compute instances for a small project or new app. For (seemingly) a few pennies, you could take full advantage of the full suite of public cloud services—as well as the scalability, elasticity, security and pay-as-you-go pricing model. All of this made it easy for teams to get started with the cloud, saving on both the IT budgets and infrastructure setup time. Public cloud providers AWS, Azure, Google Cloud, Rackspace and others made it easy to innovate.

    Fast forward several years and the early promise of the cloud is still relevant: Services have expanded, costs have (in some cases) been reduced and DevOps teams have adapted to the needs of their team by spinning up compute instances whenever they’re needed. But for many companies, the realities of their hybrid-IT infrastructure necessitates support for more than one public cloud provider. To make this work, IT Ops needs a control layer that sits on top of their infrastructure, and can deliver applications to customers over any architecture, including multicloud. This is true, no matter what the reason teams need to support multi-cloud environments.

    Prepare for the Worst

    As any IT Ops manager, or anyone who has lost access to their web app knows, outages and cloud service degradation happen. Modern Ops teams need a plan in place for when they do. Many companies choose to utilize multiple public cloud providers to ensure their application is always available to worldwide customers, even during an outage. The process of manually re-routing traffic to a second public cloud in the event of an outage is cumbersome, to say the least. Adding an app delivery control plan on top of your infrastructure allows companies to seamlessly and automatically deliver applications over multiple clouds, factoring in real-time availability and performance.

    Support Cloud-driven Innovation

    Ops teams often support many different agile development teams, often in multiple countries or from new acquisitions. When this is the case, it’s likely that the various teams are using many architectures on more than one public cloud. Asking some dev teams to switch cloud vendors is not very DevOps-y. A better option is to control app delivery automation with a cloud-agnostic control plane that sits on top of any cloud, data center or CDN architectures. This allows dev teams to work in their preferred cloud environment, without worrying about delivery.

    Avoid Cloud Vendor Lock-in

    Public cloud vendors such as Amazon Web Services or Microsoft Azure aren’t just infrastructure-as-a-service (IaaS) vendors, they sell (or resell) products and services that could very well compete with your company’s offering. In the beginning, using a few cloud instances didn’t seem like such a big deal. But now that you’re in full production and depend on one of these cloud providers for your mission-critical app, this no longer feels like a great strategy. Adding a second public cloud to your infrastructure lessens your dependence on a single cloud vendor who you may be in “coopetition” with.

    Multiple-vendor sourcing is a proven business strategy in many other areas of IT, giving you more options during price and SLA negotiations. The same is true for IaaS. Cloud services change often, as new services are added or removed, and price structures change. Taking control over these changes in public cloud service offerings, pricing models and SLAs is another powerful motivator for Ops teams to move to a multi-cloud architecture. An application delivery automation platform that can ingest and act on cloud service pricing data is essential.

    Apps (and How They’re Delivered) Have Changed

    Monolithic apps are out. Modern, distributed apps that are powered by microservices are in. Similarly, older application delivery controllers (ADCs) were built for a static infrastructure world, before the cloud (and SaaS) were commonly used by businesses. Using an ADC for application delivery requires a significant upfront capital expense, limits your ability to rapidly scale and hinders the flexibility to support dynamic (i.e. cloud) infrastructure. Using ADCs for multiple cloud environments compounds these issues exponentially. A software-defined application delivery control layer eliminates the need for older ADC technology and scales directly with your business and infrastructure.

    Regain Control

    Full support for multicloud in product may sound daunting. After all, Ops teams already have plenty to worry about daily. Adding a second cloud vendor requires a significant ramp-up period to get ready for production-level delivery, and the new protocols, alerts, competencies and other things you need to think about. You can’t be knee-deep in the details of each cloud and still manage infrastructure. Adding in the complexity of application delivery over multiple clouds can be a challenge, but much less so if you use a SaaS-based application delivery platform. With multicloud infrastructure, control is key.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services and Microsoft. Connect with him on LinkedIn.

     

  • Should You Go ‘Serverless’? The Pros and Cons

    Should You Go ‘Serverless’? The Pros and Cons

    The popularity of the “serverless” term started to grow when Amazon launched AWS Lambda in 2014. Ever since, we’ve seen the term exponentially grow in use and reference, with more vendors entering the market with their own solutions (Azure recently went GA with Functions, for example).

    What is it all about and how does this new trend affect the way people write and deploy applications? Is “serverless” a paradigm shift or just a natural evolution of infrastructure as a service (IaaS) and platform as a service (PaaS)? In this post, I will discuss what “serverless” is and is not—and how it shapes up in comparison to existing PaaS solutions.

    What is ‘Serverless’?

    “Serverless” denotes a special kind of software architecture in which application logic is executed in an environment without visible processes, operating systems, servers or virtual machines. It’s worth mentioning that such an environment is actually running on the top of an operating system and uses physical servers or virtual machines, but the responsibility for provisioning and managing the infrastructure belongs entirely to the service provider. Therefore, a software developer focuses on writing code.

    In other words, a developer thinks in terms of services or functions that communicate with each other and with the external world. After implementing these services, developers using a traditional approach would combine them into a number of distributed processes when installing, running, monitoring and updating such processes for specific operating systems that are running on specific servers or virtual machines. In the “serverless” approach, a third-party service provider is responsible for everything from the processes to the operating systems to the servers.

    When a third-party service provider is responsible for the underlying IT infrastructure, a developer no longer is in charge of purchasing a dedicated server or virtual machine. At the same time, the service provider is free to decide how to efficiently utilize its infrastructure to serve requests from all of its clients. As a result, the service provider is not usually required to run a permanent workload for a specific client; instead, the software handles requests from all of the customers at the same time, spending just a limited time on handling each request from a specific customer. Therefore, such providers usually charge their customers based on the total number of requests, the frequency of requests over a specified period or the total time spent to serve all of the requests from a customer.

    The same approach works well for different types of loads because third-party service providers usually have elastic, scalable services. When customers start using a third-party service, the expected number of requests can be low and customers pay significantly less compared to purchasing, configuring and managing their own infrastructure on-premises or in the cloud. For a larger number of requests—either expected or unexpected load peaks—customers do not need to add servers to horizontally scale their application. Instead, a service provider does care about increased load. For sure, handling a bigger number of requests will cost more, but in most cases it is still more efficient than using a dedicated IT infrastructure.

    BaaS and FaaS

    Two approaches that often are mentioned together with serverless are backend as a service (BaaS) and function as a service (FaaS).

    BaaS

    The growing number of third-party services that implement required functionality, provide server-side logic and manage their internal states has led to applications that do not have application-specific, server-side logic and use third-party services for everything. In this respect,  such applications are serverless.

    Some examples of third-party services include identity and authentication as a service (Auth0, AWS Cognito), logging as a service (Loggly, Logsense, Amazon Elasticsearch Service) and analytics as a service (Amazon Kinesis, Keen IO).

    FaaS

    When an application still requires specific server-side logic, a developer can use a modern alternative to traditional architectures: FaaS. With this approach, a developer focuses on implementing short-living stateless functions that are triggered by events and can communicate with each other and the external world. A FaaS provider does the rest—provisioning as many instances of such functions as necessary to handle all of the requests, terminate instances that are no longer required, monitor all of them and provide identity and logging services. FaaS ideally fits with microservices architecture because the FaaS provides everything that an organization needs for running microservices.

    Auth0 Webtask, AWS Lambda, Google Cloud Functions and Azure Functions are examples of FaaS implementation. IronFunctions is an ambitious initiative from Iron.io that is targeted to run AWS Lambda functionality on the most popular cloud providers as well as on-premises.

    What is Not ‘Serverless’?

    The main difference between serverless and PaaS is that traditional PaaS providers such as Heroku or OpenShift usually lack the automatic scaling feature. A user of traditional PaaS has to specify the amount of resources—such as dynos for Heroku or gears for OpenShift—for the application. It still is possible to manually scale the application up or down by changing the number of assigned resources, but mostly this is the responsibility of a developer or system administrator.

    The second difference is that traditional PaaSes are designed for long-running server applications. With such a design, the application always should be running to serve incoming requests. If you bring the application down, it obviously will not serve the requests. With FaaS, your function starts to serve a request and terminates when the request is processed. Ideally, your functions should not consume provider resources when there are no incoming requests (see also “cold start” issue below).

    Traditional PaaS implementations are not “serverless” under the strict definition of this term because they do not have automated scaling and require that server-side applications are always running so that requests can be served. Traditional container management platforms are not “serverless” for the same reasons.

    Another way to know if a provider allows the serverless approach is to identify the border between two areas of responsibility: the provider’s consumer and the provider itself. In “serverless,” the border is between application code and how is this code is actually deployed and running on physical servers. In container platforms, a platform’s consumer is still responsible for working with the operating-system level to define things such as the processes that will run in which containers and how many containers of each kind will run.

    Nonetheless, there is an inherent similarity between containers and serverless. For example, Kubernetes—an open-source container orchestration platform—allows for the automated scaling of containers using application-provided metrics such as the number of concurrent requests. AWS Lambda actually runs a container for each function.

    In other words, containers and container orchestration may provide an efficient way to implement FaaS while FaaS provides an additional abstraction level that hides specific processes, operating systems and containers from developers and allows them to focus on code.

    The Benefits and Drawbacks of “Serverless”

    As we already mentioned, “serverless” has the following main benefits:

    • Reduced time to market and quicker software release.
    • Lower operational and development costs.
    • A smaller cost to scale – there is no need for developers to implement code to scale and administrators do not need to upgrade existing servers or add additional ones.
    • Works with agile development and allows developers to focus on code and to deliver faster.
    • Fits with microservices, which can be implemented as functions.
    • Reduces the complexity of software.
    • Simplifies packaging and deployment and requires no system administration.

    At the same time, “serverless” has the following drawbacks:

    • Serverless is not efficient for long-running applications. In certain cases, using long tasks can be much more expensive than, for example, running a workload on a dedicated server or virtual machine.
    • Vendor lock-in. Your application is completely dependent on a third-party provider. You do not have a full control of your application. Most likely, you cannot change your platform or provider without making significant changes to your application. Also, you are dependent on platform availability, and the platform’s API and costs can change. Needles to say, the existing FaaS implementations are not compatible with each other.
    • Serverless (and microservice) architectures introduce additional overhead for function/microservice calls. There are no “local” operations; you cannot assume that two communicating functions are located on the same server.
    • To utilize its resources more efficiently, a service provider may run software for several different customers on the same physical server (this is also known as “multitenancy”). Even if customers’ workloads are isolated in virtual machines or containers, there can be different bugs in the early stages of FaaS offerings. This can be a major security issue for your application if you work with sensitive data. Such potential bugs in a platform or failures in one customer’s code (a “noisy neighbor”) can affect the performance or availability of your application.
    • In practice, it takes some time for a scalable serverless platform to handle a first request by your function. This problem is know as “cold start”—a platform needs to initialize internal resources (AWS Lambda, for example, needs to start a container). The platform may also release such resources (such as stopping the container) if there have been no requests to your function for a long time. One option to avoid the cold start is to make sure your function remains in an active state by sending periodic requests to your function.
    • Some FaaS implementations—such as AWS Lambda—do not provide out-of-the-box tools to test functions locally (assuming that a developer will use the same cloud for testing). This is not an ideal decision, especially considering that you will pay for each function invocation. As a result, several third-party solutions are trying to fill this gap, enabling you to test functions locally.
    • Different FaaS implementations provide different methods for logging in functions. For example, AWS Lambda allows writing logs to AWS CloudWatch using the standard frameworks for the specific language (Log4j for Java, console methods for Node.js, logging module for Python). It is completely up to the developer how to implement more advanced logging.

    Summary

    Serverless architecture is a new approach to writing and deploying application that allows developers to focus on code. Such an approach can reduce time to market, operational costs and system complexity. While serverless leverages third-party services such as AWS Lambda to eliminate the requirement to set up and configure physical servers or virtual machines, it also locks in the application and its architecture to the specific service provider. In the future, we can expect more movement toward the unification of FaaS APIs or frameworks such as IronFunctions that will help to avoid vendor lock-in and enable us to run serverless applications on different cloud providers or even on-premises.

    — Asaf Yigal