Category: Enterprise DevOps

  • Best of 2019: Five Microservices Worst Practices

    Best of 2019: Five Microservices Worst Practices

    As we close out 2019, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the first in our weeklong series of the Best of 2019.

    Microservices are moving to the mainstream. The IDC FutureScape: Worldwide IT Industry 2019 Predictions states that by 2022, 90% of all new apps will feature microservices architecture that “improve the ability to design, debug, update and leverage third-party code.”

    With so many organizations adopting or about to adopt microservices, they must be doing something right. In fact, just considering the model is a positive step toward delivering quality software, faster. However, many companies are leaving microservices benefits on the table because there are many pitfalls on the road to success. It’s about so much more than just a technology choice and starting to code microservices.

    Indeed, breaking your apps into microservices isn’t enough—you have to manage them, orchestrate them and deal with the data they create and modify. Before you even touch the keyboard it’s a good idea to think about a few points of strategy to ensure success.

    Here are five microservices worst practices and how to turn them around.

    Implementing Microservices Without the Prerequisites

    You can’t take Calculus II without taking Calculus I. Similarly, you can’t roll out microservices without the proper prerequisites. To fully leverage microservices, companies must consider modularity and domain boundaries, and the fundamental distributed systems theory should be considered and established. In addition, while each service is independent, there are operational requirements that must be met. These include DevOps; PaaS; containers or immutable VMs; service replication, registry and discovery; and proactive monitoring and alerts.

    Implementing Microservices Without Making Changes to the Development Culture

    The biggest mistake organizations make when moving to a microservices architecture model is underestimating how it’s changing the way they need to think about applications and especially the way they think about the teams developing those applications. Traditionally, there are many people involved in the development of an application, with each coming at it from his or her own perspective—the UI specialist, the middleware specialist, DBAs, sysadmins and so on. What worked for one might not work for the other when it gets thrown over the wall, and it often takes a lot of time and frustration to make everything work for everyone. Trying to do microservices without changing that model and mindset will almost certainly set your team up for failure. Instead, think in terms of cohesive, cross-functional teams, each fully responsible for its own unique services and its own set of customers for those services. Each team’s working with other teams as if it’s a business-to-business (B2B) relationship. It’s not an easy cultural transition, but it’s one that is essential for microservices to work.

    Going Too Big and Broad Out of the Gate

    An organization that goes all-in on microservices all at once is almost certain to run into problems that could completely derail the initiative altogether. Pick a small project, and staff it with people who see the potential of microservices and are excited to work with the technology. Once that project has been successfully completed, use it as a proof point to promote the further use of microservices across the organization and to get others on board.

    Misplaced Expectations

    Organizations are right to question the performance impact that microservices will have when migrating an existing monolithic application to a microservices model. But their concerns—and expectations—are often misplaced. Yes, there can be a performance hit when decomposing existing monolithic applications in favor of microservices. But what organizations need to understand is the goal of microservices is deployment speed over API invocation speed.

    Isolating the development of a service within a team (as mentioned earlier) means the service can be updated as needed—whether that’s weekly, daily or even hourly—in response to business, competitive and security demands. In its Worldwide IT Industry 2019 Predictions report, IDC notes it is “already seeing enterprises that have shifted fully to these new approaches (and supporting tools and technologies) that dramatically accelerate their ability to push out digital innovation through their organization at 50-100 times (or more) the frequency of their traditional approaches.”

    Picking the Wrong Applications to Microservice-ize

    This worst practice is linked closely to the previous one. Organizations that pick the wrong applications to split into microservices or decompose an entire monolith without thinking about which parts might be best as microservices (and which would fail miserably as microservices) will have the odds stacked against them from the get-go. A financial application or a high-volume application that makes multiple calls may not be good candidates for microservices. Or, it may be that parts of these applications would work well in the microservices model even if the monolith as a whole doesn’t. The idea is to examine each legacy application carefully and to build new applications with microservices in mind from the beginning.

    If you’re thinking that it takes a lot to establish a microservices foundation, you’re right. It’s a big investment, and it may take some time before there is a return on that investment. But organizations that move toward microservices in a thoughtful, purposeful way—exploiting the best practices of those that have gone before them—will likely find themselves more agile, more secure and more competitive.

    — Eric Schabell

  • Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

    Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

    Today, modernizing systems is more than simply moving technology to a new location. It requires an IT stack of a new generation of technologies and tools to work.

    As we head into the new year, let’s take a look at the top eight trends that will shape how we will develop and deliver software. 

    Kubernetes

    Yes, it’s big and getting bigger. The pace of enterprise adoption of this leading container orchestration solution will only gain momentum in 2020. Look no further than the 2,300% attendance increase from KubeCon 2015 (500) to KubeCon 2019 (12,000). As more companies begin to see the direct financial and operational benefits to the flexibility, scalability, automation, high availability and portability of Kubernetes, the demand for developers and engineering experts in this complex software will grow accordingly. Case in point: A 2019 national job search on LinkedIn turned up 16,744 open positions for Kubernetes-related roles. Given the already large and still developing Kubernetes community, we should also see an increase in the speed and volume of feature releases. 

    Microservices

    It’s predicted that by 2022, 90% of all apps will feature microservices architectures. The growing business imperative for software engineering teams to produce and release software in ever shorter cycles—continuous delivery—has paved the way for a huge surge in microservices, the ideal architecture for CD. As enterprises continue their accelerated move to the cloud in 2020 and beyond, they increasingly prize the flexibility to try out the new technology stacks that microservices provide. All businesses want to optimize resources, minimize downtime, reduce infrastructure costs and avoid technology or vendor lock-in. In 2020, microservices architectures will continue to offer up more and better of all these benefits as the migration from monoliths picks up speed. 

    Service meshes

    The rise of microservices has led to a parallel boom in service meshes. This will only accelerate, given how integral the current class of service meshes—Istio, Linkerd, Consul, Envoy—is to the successful functioning of microservices. As a software designed to enable the thousands of microservices that make up an application to talk to each other, it’s quickly become an essential component with a vendor ecosystem poised for substantial growth. Feature-rich Istio, backed by IBM, Google and Lyft, is the leading Kubernetes service mesh, and that shows no signs of changing in 2020, especially given the relative ease of setting up and running it. If your enterprise has embarked on the journey from monolith to microservices, it will soon be crossing paths with service meshes. 

    Observability

    In the recent past, the sheer complexity of modern distributed systems has outstripped the tools designed to allow teams to see into them. Enter observability—which isn’t monitoring. Like good helicopter parents, software engineers, application developers, SREs and DevOps teams want to know and understand what their systems are doing at all times. LightStep, Datadog and Honeycomb, to name a few, are vendors poised to offer logging, tracing and metrics solutions to the rapidly growing number of enterprise teams building cloud native systems. Keep a close eye out for OpenTelemetry, an open source observability framework currently a member of the CNCF Sandbox. 

    SRE

    One of the great challenges ahead for this still-emerging field is for enterprises of varying sizes and work cultures to find a form of SRE that works. What succeeds at Google may not be the recipe for SRE implementation at smaller tech enterprises or startups. The role of SRE and the expectations that go with it remain fluid. The SRE’s constant imperative to automate will only add to the profile of critical SRE and DevOps tools such as Terraform, Ansible and Jenkins. Ponder Amazon’s Prime Day 2018 losses of up to $99 million for a clear understanding of the business-critical importance of SREs in the years to come. The job market reflects this new reality. 

    Security

    The shift-left movement in the software development lifecycle is on. The days of bolted-on post-production security are rapidly fading. DevSecOps, though still a buzz term, is here to stay, with more practice and use cases added to the theory. There are huge opportunities here for automated application security tools that support the software development workflow. 

    Then there’s privacy. The GDPR took effect last May and the California Consumer Privacy Act takes effect January 1, 2020. On top of these, there’s HIPAA and the regulatory compliance pressures on businesses in the area of security, which are already enormous—plus the immense challenges of cloud security. A 2019 Symantec survey on cloud security threats reports that 65% of businesses in the cloud still aren’t using multi-factor authentication. The same survey also notes that an astounding 85% of Symantec’s cloud customers aren’t employing security best practices. Look for businesses to tend to security earlier in the process. 

    Serverless

    It’s a boom time in serverless, with Google’s Functions, Microsoft’s Azure Functions and IBM’s OpenWhisk all offering their serverless solutions following the 2014 rollout of AWS Lambda. Look for more businesses to adopt a serverless-first approach as they upgrade legacy systems and see the substantial cost saving and application development benefits. Startups, too, will see the cost-cutting upside and the agility that serverless brings. The changes in application development and architecture in the cloud as a result of serverless are hard to overstate. With the vendor solutions now on offer, developers are freed up to do what they most like to do: run code and add functionality to their application, faster, without worrying about scaling and availability. Like microservices, serverless will see a huge upsurge in usage as the age of the monolith fades. 

    DevOps

    With the demands of cloud computing and far greater enterprise investment in dedicated teams, DevOps in 2020 is poised to make the transition from policies and principles to actual practice. The addition of baked-in security to the DevOps realm—DevSecOps—adds urgency to the automation of building, provisioning and deploying secure software. ML- and AI-driven apps have arrived, and DevOps practices will play a large role in the development workflow. The goal of zero-touch automation looms large, and this adds urgency to the need for clean data, organizational buy-in and more integrated systems. AIOps, though getting plenty of attention, is still young and its benefits to IT operations are still more theoretical than actual–but stay tuned.

    As we head into 2020, it will be exciting to watch these trends unfold. DevOps teams can expect the way we develop and deploy applications–in any architecture–to continue to evolve. By keeping a pulse on new developments in Kubernetes, microservices and other new technologies, they’ll be well prepared to bring their businesses into the new decade.

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

    — Kelsie Pallanck

  • Don’t Expect Miracles

    Don’t Expect Miracles

    Let’s run some fun scenarios to start this one off, shall we?

    • “We’ll decide what language to use at a meeting next month. Until then, get to writing code!”
    • “We might deploy internally, though Azure is a strong option, and we’ve discussed GCP. Now get operations up and running, we’ll tell you when we’ve decided.”
    • “The code is changing constantly, get moving and write the documentation.”

    All three of these scenarios are equivalent. The difference is how we, as an industry, view them. The first two, we (collectively) would never tolerate. The third? We do that to the documentation team every day. In DevOps and agile, we do it every day in a never-ending iteration. And it has to stop.

    Two Different Documentations

    For those not aware, there is documentation for internal use and documentation for external use. While we’re certain you have internal covered with self-documenting code, this blog will focus on external use, because if you expose and API, documentation is mandatory. If you’re not an end-user product, any UI requires documentation, too. So to be clear, for this blog we are talking generally about external documentation for B2B systems, and specifically about APIs, though UIs can have the same issues, depending upon how complex your market is.

    We Generate Docs

    Ever tried to use auto-generated documentation? I’ve yet to try one generated set of API documentation that I liked (they say Google Places has it, but my understanding is devs actually write that documentation and it’s reviewed by tech writers, so maybe we count that as one I liked, but its process is not yours).

    Generated docs are only as good as the developers working on the code–very much like self-documenting code. If someone puts “This parameter is a placeholder for the spline development iteration” into a generatable comment, users are going to be totally clueless what that means. Heck, I just dreamed that statement up, and while we can all see it turning up in generated API docs, even I don’t know what it might mean.

    Documentation Slows Up Dev

    Duh? If you are loathe to commit to completing a project until you know the parameters, why would you expect a documentation team to be any different? Of course they need the final product for review, just as the business wants to see the final app before release. The product your docs team produces is detailed documentation about what is. If you change what is underneath them, they look bad for having inaccurate docs. When really it should be IT that looks bad for not considering the entire value chain when delivering. If you deliver an API that is poorly documented and people don’t use it, you have delivered nothing of value to the organization.

    What to Do?

    Put documentation on your DevOps teams. I mean an actual person whose responsibility is documenting. If you’ve got technical writers, use one of them. If you don’t, find someone who likes helping people use your toys, and give them time to do it. For some organizations, technical evangelists can fulfill this role if you don’t have them too busy helping active users. Have them sit in on meetings, treat them as just another piece of both agile and DevOps. They need to know when functionality, URI or whatever else changes, so they can update the docs. The best place to get that info is at stand-ups or design meetings.

    Just like always, they’ll want to be there for design, but they’ll also want to be there for implementation decisions/changes. Because current documentation is the only worthwhile documentation. Give them sign off on release–not release of code (that’s a done deal) but publication of APIs. Before you let users at the access points, make sure they have solid instructions in how to use them.

    Risks

    Everything is a trade-off, but this one has some pretty easy choices to make–fewer people use your API because your documentation isn’t great (outright sucks in many cases), or you run some risks of slower iterations and you dedicate resources to documentation. Given that if no one uses your API, it is all wasted time, a bit of slow-down and man-hour investment is an easy choice to make.

    Tech writers are generally cautious people who want perfection–because this is their product, and they want it right. This can cause unnecessary slow-downs in an agile/DevOps world. The easy answer here is to look for the same traits in documentation DevOps team members that you look for in other DevOps team members–ability to adapt, understanding that everyone is just trying to make it better and willingness to work through changes quickly to deliver.

    Just like you don’t want the DBA that says “no” to every request and you have to argue with just to move the project forward–I worked with this guy, genius, but really frustrating to have on an agile team–you don’t want the documentation person that adds weeks to timelines so they can get it right. This risk is easy to manage. You know how to choose people for a fast-moving environment, just follow your gut.

    Profit

    Well, okay, maybe not profit, but deliver a solid product quickly with sufficient documentation that users not steeped in your corporate shared knowledge will understand and be able to use. That’s the goal of public-facing APIs, to be used. And it’s the goal of docs people to make certain those calling the APIs understand what they’re getting into and how to make the most of it.

    Keep on cranking out cool solutions and crank out better docs. Your customers are counting on it. I’ve had my team go find alternative solutions based on shoddy API documentation. If I can’t use it, why would I keep trying if there are alternatives?

    — Don Macvittie

  • Predictions 2020: Key Trends that Will Shape the Autonomous Digital Enterprise

    Predictions 2020: Key Trends that Will Shape the Autonomous Digital Enterprise

    As 2019 comes to an end, and we look toward trends driving innovation in 2020 and beyond, technology advancements in hyper automation, AIOps, edge computing and the convergence of IT service management and IT operations management will be at the forefront. 

    Autonomous Digital Enterprise

    In order to thrive in the 2025 futurescape, organizations will need to evolve to Autonomous Digital Enterprises (ADE), a state where intelligent, integrated, value-creating functions can operate with minimal (ideally zero) human involvement or interference, across every facet of the organization, and its ecosystem of partners.

    This concept is based on the notion that every company today is being disrupted by technology and that’s fundamentally changing their business model. The notion of every company being a technology company means that software becomes more than just a system of record to be the system of action, the system of insights and the system of engagement.

    Edge Computing and IoT

    Over the next couple of years, partnerships will prove to be the pathway to success in realizing value from edge computing and IoT solutions. By using seamlessly integrated, multi-vendor, commercial off-the-shelf solutions, enterprises will experience more success than they would with single-vendor niche products. At the end of the day, what we need is an ecosystem of integrated solutions as opposed to a single silver bullet. This ecosystem will be able to harness data and look at it in meaningful ways and translate information into insight that then translates into actions that businesses can take to optimize the use of IoT assets.

    Convergence of IT Service Management and IT Operations Management

    As IT service management and IT operations continue to converge in 2020, CIOs will rely on AI. More than ever, CIOs will need to address this convergence and work to break down silos between these departments. To obtain a comprehensive view of the IT landscape, CIOs will begin to adopt AI, cognitive and robotic process automation. This will bring end-user support and managed back-end infrastructure more closely together. 

    If we look beyond traditional IT and service management, in the near future we will have the ability to go to market with fully integrated solutions that enable boundary-less operations across AppDev, SecOps, ITOps and service management. This will further enable the use of DevOps in organizations using the power of AI to improve existing capabilities and create new capabilities. This doesn’t mean companies have to start from the ground up on AI efforts, rather they need to look for software solutions that can offer prebuilt AI/ML solutions that drive change.

    AIOps

    The demand for AIOps in the enterprise will continue to rise as AI and machine learning have taken the industry by the jugular. Due to an expansion in the number of workloads—both in public cloud and on-premises—and an increase in application complexity, investment in AIOps will increase and ultimately lead to better business outcomes. Today’s challenges place a premium on differentiated vendor solutions powered by AI/ML and big data analytics techniques that can help modern IT operations evolve from traditional monitoring to observability to actionability.

    All of these trends open realms of possibilities for what businesses can achieve in 2020—as long as they can harness the massive amounts of data enterprises have access to and the technology that will allow them to unlock those insights.

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

    — Ram Chakravarti

  • Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

    Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

    DevOps has become a hot strategy for IT teams across just about every industry—and for good reason. DevOps is built around increasing the velocity of the development pipeline, and in businesses where time to market is a key to success, it’s easy to imagine why DevOps has gained traction. While the tools and processes put in place are certainly essential, building the right team—from top to bottom—is maybe the most important factor for getting the most out of a DevOps strategy.

    To help get the most out of DevOps initiatives—and to set teams up for long-term, sustained success—here are some basic tips for creating the team that will take development pipelines to new heights.

    Change Is Coming

    When kicking off a DevOps strategy, it’s clear that changes will be made. But, the extent of those changes may be underestimated. To get the most out of DevOps, it’s not just about changing up the tool stack or switching up meeting styles. The mindset around DevOps is at least as important as the processes. To squeeze the most juice out of a DevOps initiative, make sure the company and leadership understand what all DevOps entails and create the understanding that it requires a lot of internal changes to the existing culture. Getting leadership on board with the cultural changes that come with DevOps will go a long way toward driving success.

    Talent Talks

    This may go without saying, but it is imperative to build a team with the right skills for the task at hand. It can be easy to try to shoehorn people into roles, especially when trying to move quickly. But make sure to set individual talent up for success—both employees and the company will benefit. This means having DevOps engineers and leadership with the skills—whether they are technical, interpersonal or something else—to perform the work required.

    Get Your Budget Right

    DevOps helps create efficiencies. Leveraging automation, maximizing value delivery and getting products to market faster are all key tenets of a good DevOps strategy. But that doesn’t mean you should skimp on the important items. Like any project worth doing, it’s a lot easier (and more successful) when it is budgeted properly.

    Make sure to have an adequate budget to create a team, perform the work and support the appropriate environments and infrastructure to perform the DevOps tasks and initiatives that need to be done. Doing this in advance will save a lot of headaches down the line and help develop a clear understanding of what is really needed to get from point A to point B—and help keep spending in line while the DevOps train is moving.

    It’s Not Just About IT

    Remember there are two parts to DevOps—dev and ops. It is often easier to get the developer side to buy into the strategy—after all, many of the tenets of DevOps speak to the technical teams. But overall buy-in is necessary for cooperation and involvement of all teams needed to achieve goals. That means development and operations—plus other departments within the organization, such as sales, marketing, the executive team, etc. Getting everyone on board with the process and rowing in the same direction will fundamentally change the mindset around how to design and deliver products. When the whole team is moving in lockstep, that’s when success can really be visualized.

    By keeping the thoughts above in mind when planning a DevOps journey, organizations can help ensure teams are organized and set up for long-term success. But remember, every organization is different and has different requirements. What may work for one organization may not for the next.

    When considering the potential of DevOps for your organization, it can be tempting to dive right in and skip some important considerations for setting up the initiative. But the key points listed above are tried-and-true and carry weight, no matter the size or scope of business. Having a leader who acts as a champion for DevOps efforts is essential, so IT professionals tasked with leading the organization into the DevOps transformation should arm themselves with these tips to be better positioned for success.

    — Jonathan Fries

  • Predictions 2020: The Year of DevOps Empowerment

    Predictions 2020: The Year of DevOps Empowerment

    Every year since mid-decade, it seems, one publication or another has declared it to be “the year of DevOps.” Allow me to make the case that it really will happen in 2020.

    The reason? IT leaders are finally empowering their engineers with full-service ownership.

    In a world in which speed, quality and precision will continue to determine the difference between continued success and unmerciful failure–particularly with regard to delivering best-in-class, end-to-end experiences for all stakeholders–full-service ownership is a matter of reality and necessity. Not to mention common sense.

    Developing and delivering products and services that maintain pace and meet the needs of businesses is dependent on achieving faster release cycles without sacrificing quality. But running reliable systems at ever-increasing speeds presents huge challenges that software teams can meet by changing their service ownership policies. The good news is DevOps practices have been gaining considerable traction because they help teams deliver with increased velocity coupled with reduced risk. This enablement, similar to any change introduced, takes time and practice to make work for your needs.

    Code It, Ship It, Own It

    Full-service ownership grants engineers greater responsibility for the code they write and the services they develop during production. The importance of owning and operating your own code and taking responsibility for all deliverables should not be underestimated, because it is the engineers, after all, who should be–and have earned the right to be–accountable. They are the ones designing architectures and systems, coding software and writing runbooks. They are the ones on whose shoulders the overall quality of service sits. They are the ones who are on call when issues arise (invariably, as Murphy’s Law implies, in the middle of the night).

    If they are the ones who code it, then they are the ones who should ship it and own it. The days of engineers “throwing code over the wall” to operations or depending on site reliability engineering (SRE) teams to guarantee the performance of services in the wild are no longer relevant, much less workable.

    That’s particularly important going forward, considering the DevOps market is predicted to grow 18% to nearly $13 billion by 2025. As DevOps tools and solutions become more ingrained in IT operations, the most logical and proactive way to manage this growth, and the inevitable chaos it will bring, is to empower IT with full-service ownership.

    The Forces Behind Full-Service Ownership

    This is happening for three reasons:

    Accountability

    It’s a simple truth; consumers implicitly expect the services they use to work seamlessly and with minimal latency. Considering that consumers will simply move to another site when a page is slow to load or returns a 404 error, the payoff in terms of increasing business’ competitive advantage is immense.

    Full-service ownership promotes higher-quality work because it gives engineers clear visibility into how the code and services they’ve created are performing and impacting their customers’ daily activities. 

    Reliability

    It’s not rocket science to ask the scientist who built the rocket to fix it when it breaks. Likewise, businesses can reduce the amount of downtime and customer impact when a serious incident occurs by immediately bringing in the engineers who wrote the code or created the service. 

    Full-service ownership offers another important advantage: overall institutional knowledge among IT teams. Individual engineers benefit greatly from code reviews, on-call hand-offs, daily standups, casual information sharing and other exercises that build redundancy in knowledge and expertise.

    Continuous Improvement

    A common misconception in the engineering world is that “on-call” is synonymous with “always-on.” That in itself is counter-productive because it can lead directly to alert fatigue. In an ideal world, teams will build time in their development work to go “off-call,” a practice that alleviates alert fatigue and that full-service ownership encourages.

    It also fits perfectly with an integral element of the culture of engineers: a commitment to continually refine and improve their code, product, services and alerting. The most effective process goes beyond just fixing problems, it also includes getting ahead of them, by automating the work needed to prevent them, freeing engineers up to focus on the work that matters most. 

    Five Benefits of Full-Service Ownership

    1. The quality of the code will increase.
    2. Engineers will know when they are off-call, and alerts will be covered by another developer with equal expertise.
    3. Team knowledge and skills will increase through a deeper understanding of the codebase.
    4. Services will become more reliable.
    5. Operations will become more agile.

    When engineers are empowered to code it, ship it and own it, businesses put themselves in a better position to enhance the customer experience and reduce the impact of disruptions, which enables them to focus more on innovation. By defining and refining roles and responsibilities, full-service ownership also reduces the chaos associated with incidents, eliminates silos and unnecessary layers and, ultimately, promotes a culture of empowerment and accountability.

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

    — Tim Armandpour

  • DevOps at Longtail UX

    DevOps at Longtail UX

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

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

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

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

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

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

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

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

    Avoiding Vendor Dependence

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

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

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

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

    Growth

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

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

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

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

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

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

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

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

    — Stephen Withers

  • Predictions 2020: Five Real-Time Data Predictions

    Predictions 2020: Five Real-Time Data Predictions

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

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

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

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

    Machine Learning and AI Models Finally Get the Data They Deserve

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

    Privacy Prompts a New Era of Data Innovation

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

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

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

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

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

    5G Will Accelerate Customer Expectations

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

    Decline of Globalization Will Force Companies to Know Their Customers Better

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

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

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

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

    — Lenley Hensarling

  • App Mobility Is the New Use Case

    App Mobility Is the New Use Case

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

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

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

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

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

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

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

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

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

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

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

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

    — Don Macvittie

  • Social Media Marketing for Businesses

    Social Media Marketing for Businesses

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

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

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

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

    Let’s dive in.

    What’s the Meaning of Social Media Marketing?

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

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

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

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

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

    What Are the Benefits of SMM?

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

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

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

    Here are just a few benefits of SMM:

    Boost in Website Traffic

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

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

    Increased Brand Awareness

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

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

    Social Media Marketing is Cheap

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

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

    Increased Conversion

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

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

    It’s Flexible

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

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

    How to Do SMM the Right Way

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

    Set Your SMM Goals

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

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

    Choose a Target Social Audience

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

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

    Plan Your Posts 

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

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

    Bottom Line

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

    — Wendy Dessler