staging-devopsy.kinsta.cloud

Tag: messaging

  • AWS Aligns With Slack to Foster Dev Team Collaboration

    AWS Aligns With Slack to Foster Dev Team Collaboration

    Amazon Web Services (AWS) and Slack Technologies have formed an alliance through which they are moving to transform the way development teams collaborate.

    Under the terms of the multi-year agreement, Slack will migrate voice and video calls to the Amazon Chime real-time communications service.

    In addition, AWS and Slack are integrating Amazon AppFlow integration with Slack, which enables data to be transferred securely between Slack and AWS services such as Amazon Simple Storage Service (Amazon S3) and Amazon Redshift. The two companies are also promising to make it possible to transfer data bi-directionally between multiple Slack channels and AWS services in a single flow.

    AWS and Slack have also integrated the AWS Key Management Service with Slack Enterprise Key Management (EKM) to distribute and control cryptographic keys. That capability builds on an instance of EKM for Slack’s Workflow Builder automation tool that was released last month.

    Finally, the two companies are committing to make the AWS Chatbot service accessible from directly within Slack.

    Slack, which already makes extensive use of the AWS cloud, has emerged as a de facto collaboration tool within many organizations that have embraced best DevOps practices. Eron Kelly, head of product marketing for AWS, said this alliance will make it easier for development teams to employ a wide range of communications tools at scale.

    Many DevOps teams already rely on Slack Calls to launch video and voice calls whenever a subject being discussed using text messages requires a deeper level of interaction. As reliance on Slack Calls increases, the software development kit (SDK) for the AWS Chime service that Slack will invoke will ensure the quality of the video and voice calls, said Kelly.

    In many ways, DevOps processes revolve around a mix of asynchronous and synchronous communications. The challenge has been to find a way to enable DevOps teams to use those tools in a way that enhances rather than detracts from productivity. Managing multiple Slack communications channels can easily become overwhelming, especially if developers are working on multiple projects at the same time.

    Ideally, DevOps teams will eventually become more adept at determining, for example, what messages, such as status updates, are best delivered asynchronously versus urgent requests that need to be made via a communications medium such as Slack.

    In the meantime, the COVID-19 pandemic has clearly increased reliance on communications services delivered via the cloud. With most members of DevOps teams working from home, tools such as Slack have become a virtual substitute for walking over to the next cube in an office to resolve an issue. Once development teams return to the office, it will be interesting to see to what degree tools such as Slack have become the default means of communication, even with fellow employees who may be only a few feet away. In fact, such tools may play a critical role in helping organizations adhere to social distancing policies even after employees return to the office.

    As philosopher Marshall McLuhan once observed, the medium is the message. Today, however, those messages increasingly are being delivered within a stream of real-time communications that is becoming more challenging to manage.

  • NATS Messaging Entering Cloud Native Purview

    NATS Messaging Entering Cloud Native Purview

    The Cloud Native Computing Foundation (CNCF) has expanded the scope of its purview by adding open source NATS messaging software to an expanding list of technologies it now oversees.

    NATS messaging software has been commonly employed in environments such as platform-as-a-service (PaaS) environments. But with the rise of microservices, a campaign to make NATS a part of the portfolio of technologies that members of CNCF consortium will advance has begun in earnest, said Derek Collison, who lead the development of NATS and is now CEO of Synadia Communications, which is dedicated to enabling organizations to more easily deploy and manage messaging systems based on NATS.

    The ultimate goal, Collison said, is to not only make messaging ubiquitous, but also effectively invisible.

    Collison said he and the CNCF envision a world where messaging just comes baked into every application. PaaS environments may have driven mainstream adoption of NATS messaging to integrate various elements of an application, but microservices will make messaging a fundamental requirement for building applications that can efficiently scale, he said, adding too many organizations already run into these issues because they are depending on HTTP to integrate various microservices.

    NATS is already widely employed by a number of vendors and organizations including Apcera, Apporeto, Baidu, Bridgevine, Capital One, Clarifai, Cloud Foundry, Comcast, Ericsson, Faber, Fission, General Electric, Greta, HTC, Logimethods, Netlify, Pex, Pivotal, Platform9, Rapidloop, Samsung, Sendify, Sensay, StorageOS, VMware Acadiant, Weaveworks and Workiva.

    The core NATS server and NAT Streaming software are maintained by Synadia. There are clients for Python, Ruby, Node.js, Elixir, Java, NGINX, C and C#, as well as third-party contributions that add support for Arduino, Rust, Lua, PHP, Perl and others.

    Longer term, Collison sees NATS evolving to include functionality to support real-time applications, many of which today are using Apache Kafka software. Rather than having to deploy NATS and Kafka for different use cases, Collison said it will make more sense to have a common control plane to address multiple classes of use cases for messaging.

    Messaging systems in one form or another have been at the heart of integration platforms for decades now. But the assumption was always that integration would be addressed after the applications were deployed. In the future, the assumption is that all cloud-native applications need to be integrated, which is much easier to accomplish if they all come with some form of messaging capability baked in. Integrating and managing federated instances of messaging systems still will be required. But much of the lower-level functions now being centrally processed will be pushed out into the applications being integrated.

    Collison is the first to admit that messaging is not some new, emerging technology. But as microservices architectures continue, messaging will prove to be core to a new generation of cloud-native applications, he said. The CNCF is clearly betting that a consortium of vendors working on a common code base for messaging will accomplish that goal a whole lot sooner.

    — Mike Vizard

  • Tailoring Enterprise Collaboration: Strategies for Success

    Tailoring Enterprise Collaboration: Strategies for Success

    In the age of SCRUM, Agile and DevOps, developers collaborate with their peers and colleagues more than ever before. Many developers already use a variety of collaboration tools on a daily basis, such as a team messaging application, an online discussion forum, or an open code repository.

    But while developers love to collaborate, it can be easy for them to forget that not everyone collaborates the same way. By focusing solely on collaboration products and solutions that work well for their development teams, developers are missing the opportunity to provide tailor-made collaboration capabilities to the applications they’re building, or to their entire company or organization. When it comes to developing collaboration capabilities for their organization, developers often fall short of business expectations, as their own personal needs differ from their constituents.

    Tailor-Made Collaboration

    Here are three recommendations on how to tailor a collaboration solution that will fit well for an entire organization:

    Beware of the “One Size Fits All” Approach

    Today’s array of collaboration tools is more sophisticated than many developers realize. In fact, incorrect assumptions about which platforms are “best of breed” result in rolling out collaboration technology that may have technical but not business, appeal. As many developers hold the keys to the platforms that are eventually put into practice within their organization, this leaves executives at the hands of those who often see collaboration platforms as group chat spaces and wikis for sharing code.

    However, other lines of business don’t only collaborate with chats or wikis. A business with thousands of employees located around the world cannot only use general correspondence streams to acquire the information they need to successfully do their jobs. It is unrealistic to expect that messaging platforms alone can support groups of people across departments who do not necessarily understand one another. For instance, IT and Marketing departments’ daily operations are far from the same—so then why would a “one size fits all” approach for workplace teamwork be successful?

    Developers must look beyond topline technologies and examine a full range of collaboration solutions that can also provide centralized repositories for information, customized landing pages and unified communication capabilities.

    Identify and Understand Communication Gaps in Business Processes

    As departments differ, mindsets across organizations vary as well. The developer creating the back end of the platform operates in a unique workflow and framework from those utilizing the platform. It is, therefore, critical to demonstrate a clear integration between different levels of the organization to create a unified understanding of how people work.

    Individuals who rely on each other to accomplish tasks need to interact in a variety of ways, including through a centrally located platform to converse on ideas and join forces on project development. To create useful online spaces, developers should attend meetings with other teams to truly understand their needs. By doing so, they will gain perspective on how their peers operate in the workplace, and develop a platform that is increasingly applicable and effective.

    Build a Plan for Scale and Growth

    By better understanding business needs, developers can predict the appropriate scaling requirements for their collaboration solution. Scaling a collaboration solution may involve setting up workspaces and areas for mass access to thousands or tens of thousands of people, but many of the leading tools cannot scale past several thousand users. For global businesses with multiple constituents and varying workflows, messaging-based approaches may not suffice on their own, as they are not scalable methods to distribute content to a high volume of people.

    Ultimately, enterprise collaboration work patterns are shifting toward more speed, and developers are at the heart of the transition. However, being overly reliant on the technical appeal of specific collaboration tools will not lead to the best outcomes for the business.  Developers need to design and build collaboration solutions that not only assist their colleagues to communicate, but also help drive collaboration that impacts business outcomes at scale. By understanding the nature of the way an organization needs to collaborate, developers can provide solutions that directly contribute to increased revenue, empowering them as strategic partners in organizational change.

    About the Author / Stephen Hamrick

    Stephen Hamrick is VP Product Management, Collaboration Software at SAP. Based in Palo Alto, California, Steve leads the product management, user experience, and documentation teams for enterprise social software products at SAP. He has spent the last 20 years of his career in the enterprise software technology industry, focused primarily on collaboration and social software. Connect with him on LinkedIn and Twitter.