software development
Auto Added by WPeMatico
3 questions to ask before adopting microservice architecture
As a product manager, I’m a true believer that you can solve any problem with the right product and process, even one as gnarly as the multiheaded hydra that is microservice overhead.
Working for Vertex Ventures US this summer was my chance to put this to the test. After interviewing 30+ industry experts from a diverse set of companies — Facebook, Fannie Mae, Confluent, Salesforce and more — and hosting a webinar with the co-founders of PagerDuty, LaunchDarkly and OpsLevel, we were able to answer three main questions:
- How do teams adopt microservices?
- What are the main challenges organizations face?
- Which strategies, processes and tools do companies use to overcome these challenges?
How do teams adopt microservices?
Out of dozens of companies we spoke with, only two had not yet started their journey to microservices, but both were actively considering it. Industry trends mirror this as well. In an O’Reilly survey of 1500+ respondents, more than 75% had started to adopt microservices.
It’s rare for companies to start building with microservices from the ground up. Of the companies we spoke with, only one had done so. Some startups, such as LaunchDarkly, plan to build their infrastructure using microservices, but turned to a monolith once they realized the high cost of overhead.
“We were spending more time effectively building and operating a system for distributed systems versus actually building our own services so we pulled back hard,” said John Kodumal, CTO and co-founder of LaunchDarkly.
“As an example, the things we were trying to do in mesosphere, they were impossible,” he said. “We couldn’t do any logging. Zero downtime deploys were impossible. There were so many bugs in the infrastructure and we were spending so much time debugging the basic things that we weren’t building our own service.”
As a result, it’s more common for companies to start with a monolith and move to microservices to scale their infrastructure with their organization. Once a company reaches ~30 developers, most begin decentralizing control by moving to a microservice architecture.
Teams may take different routes to arrive at a microservice architecture, but they tend to face a common set of challenges once they get there.
Large companies with established monoliths are keen to move to microservices, but costs are high and the transition can take years. Atlassian’s platform infrastructure is in microservices, but legacy monoliths in Jira and Confluence persist despite ongoing decomposition efforts. Large companies often get stuck in this transition. However, a combination of strong, top-down strategy combined with bottoms-up dev team support can help companies, such as Freddie Mac, make substantial progress.
Some startups, like Instacart, first shifted to a modular monolith that allows the code to reside in a single repository while beginning the process of distributing ownership of discrete code functions to relevant teams. This enables them to mitigate the overhead associated with a microservice architecture by balancing the visibility of having a centralized repository and release pipeline with the flexibility of discrete ownership over portions of the codebase.
What challenges do teams face?
Teams may take different routes to arrive at a microservice architecture, but they tend to face a common set of challenges once they get there. John Laban, CEO and co-founder of OpsLevel, which helps teams build and manage microservices told us that “with a distributed or microservices based architecture your teams benefit from being able to move independently from each other, but there are some gotchas to look out for.”
Indeed, the linked O’Reilly chart shows how the top 10 challenges organizations face when adopting microservices are shared by 25%+ of respondents. While we discussed some of the adoption blockers above, feedback from our interviews highlighted issues around managing complexity.
The lack of a coherent definition for a service can cause teams to generate unnecessary overhead by creating too many similar services or spreading related services across different groups. One company we spoke with went down the path of decomposing their monolith and took it too far. Their service definitions were too narrow, and by the time decomposition was complete, they were left with 4,000+ microservices to manage. They then had to backtrack and consolidate down to a more manageable number.
Defining too many services creates unnecessary organizational and technical silos while increasing complexity and overhead. Logging and monitoring must be present on each service, but with ownership spread across different teams, a lack of standardized tooling can create observability headaches. It’s challenging for teams to get a single-pane-of-glass view with too many different interacting systems and services that span the entire architecture.
Powered by WPeMatico
Arrikto raises $10M for its MLOps platform
Arrikto, a startup that wants to speed up the machine learning development lifecycle by allowing engineers and data scientists to treat data like code, is coming out of stealth today and announcing a $10 million Series A round. The round was led by Unusual Ventures, with Unusual’s John Vrionis joining the board.
“Our technology at Arrikto helps companies overcome the complexities of implementing and managing machine learning applications,” Arrikto CEO and co-founder Constantinos Venetsanopoulos explained. “We make it super easy to set up end-to-end machine learning pipelines. More specifically, we make it easy to build, train, deploy ML models into production using Kubernetes and intelligent intelligently manage all the data around it.”
Like so many developer-centric platforms today, Arrikto is all about “shift left.” Currently, the team argues, machine learning teams and developer teams don’t speak the same language and use different tools to build models and to put them into production.
Image Credits: Arrikto
“Much like DevOps shifted deployment left, to developers in the software development life cycle, Arrikto shifts deployment left to data scientists in the machine learning life cycle,” Venetsanopoulos explained.
Arrikto also aims to reduce the technical barriers that still make implementing machine learning so difficult for most enterprises. Venetsanopoulos noted that just like Kubernetes showed businesses what a simple and scalable infrastructure could look like, Arrikto can show them what a simpler ML production pipeline can look like — and do so in a Kubernetes-native way.
Arrikto CEO Constantinos Venetsanopoulos. Image Credits: Arrikto
At the core of Arrikto is Kubeflow, the Google -incubated open-source machine learning toolkit for Kubernetes — and in many ways, you can think of Arrikto as offering an enterprise-ready version of Kubeflow. Among other projects, the team also built MiniKF to run Kubeflow on a laptop and uses Kale, which lets engineers build Kubeflow pipelines from their JupyterLab notebooks.
As Venetsanopoulos noted, Arrikto’s technology does three things: it simplifies deploying and managing Kubeflow, allows data scientists to manage it using the tools they already know, and it creates a portable environment for data science that enables data versioning and data sharing across teams and clouds.
While Arrikto has stayed off the radar since it launched out of Athens, Greece in 2015, the founding team of Venetsanopoulos and CTO Vangelis Koukis already managed to get a number of large enterprises to adopt its platform. Arrikto currently has more than 100 customers and, while the company isn’t allowed to name any of them just yet, Venetsanopoulos said they include one of the largest oil and gas companies, for example.
And while you may not think of Athens as a startup hub, Venetsanopoulos argues that this is changing and there is a lot of talent there (though the company is also using the funding to build out its sales and marketing team in Silicon Valley). “There’s top-notch talent from top-notch universities that’s still untapped. It’s like we have an unfair advantage,” he said.
“We see a strong market opportunity as enterprises seek to leverage cloud-native solutions to unlock the benefits of machine learning,” Unusual’s Vrionis said. “Arrikto has taken an innovative and holistic approach to MLOps across the entire data, model and code lifecycle. Data scientists will be empowered to accelerate time to market through increased automation and collaboration without requiring engineering teams.”
Image Credits: Arrikto
Powered by WPeMatico
Now may be the best time to become a full-stack developer
Sergio Granada
Contributor
Contributor
Sergio Granada is the CTO of Talos Digital, a global team of professional software developers that partners with agencies and businesses in multiple industries providing software development and consulting services for their tech needs.
In the world of software development, one term you’re sure to hear a lot of is full-stack development. Job recruiters are constantly posting open positions for full-stack developers and the industry is abuzz with this in-demand title.
But what does full-stack actually mean?
Simply put, it’s the development on the client-side (front end) and the server-side (back end) of software. Full-stack developers are jacks of all trades as they work with the design aspect of software the client interacts with as well as the coding and structuring of the server end.
In a time when technological requirements are rapidly evolving and companies may not be able to afford a full team of developers, software developers that know both the front end and back end are essential.
In response to the coronavirus pandemic, the ability to do full-stack development can make engineers extremely marketable as companies across all industries migrate their businesses to a virtual world. Those who can quickly develop and deliver software projects thanks to full-stack methods have the best shot to be at the top of a company’s or client’s wish list.
Becoming a full-stack developer
So how can you become a full-stack engineer and what are the expectations? In most working environments, you won’t be expected to have absolute expertise on every single platform or language. However, it will be presumed that you know enough to understand and can solve problems on both ends of software development.
Most commonly, full-stack developers are familiar with HTML, CSS, JavaScript and back-end languages like Ruby, PHP or Python. This matches up with the expectations of new hires as well, as you’ll notice a lot of openings for full-stack developer jobs require specialization in more than one back-end program.
Full-stack is becoming the default way to develop, so much so that some in the software engineering community argue whether or not the term is redundant. As the lines between the front end and back end blur with evolving tech, developers are now expected to work more frequently on all aspects of the software. However, developers will likely have one specialty where they excel while being good in other areas and a novice at some things… and that’s OK.
Getting into full-stack, though, means you should concentrate on finding your niche within the particular front-end and back-end programs you want to work with. One practical and common approach is to learn JavaScript because it covers both front and back-end capabilities. You’ll also want to get comfortable with databases, version control and security. In addition, it’s smart to prioritize design, as you’ll be working on the client-facing side of things.
Because full-stack developers can communicate with each side of a development team, they’re invaluable to saving time and avoiding confusion on a project.
One common argument against full stack is that, in theory, developers who can do everything may not do one thing at an expert level. But there’s no hard or fast rule saying you can’t be a master at coding and also learn front-end techniques, or vice versa.
Choosing between full-stack and DevOps
One hold up you may have before diving into full-stack is you’re also mulling over the option to become a DevOps engineer. There are certainly similarities among both professions, including good salaries and the ultimate goal of producing software as quickly as possible without errors. As with full-stack developers, DevOps engineers are also becoming more in demand because of the flexibility they offer a company.
Powered by WPeMatico
Five VCs discuss how no-code is going horizontal across the world’s industries
Few topics garner cheers and groans quite as quickly as the no-code software explosion.
While investors seem uniformly bullish on toolsets that streamline and automate processes that once required a decent amount of technical know-how, not everyone seems to think that the product class is much of a new phenomenon.
On one hand, basic tools like Microsoft Excel have long given non-technical users a path toward carrying out complex tasks. (There’s historical precedent for the perspective.) On the other, a recent bout of low-code/no-code startups reaching huge valuations is too noteworthy to ignore, spanning apps like Notion, Airtable and Coda.
The TechCrunch team was interested in digging in to what defines the latest iteration of no-code and which industries might be the next target for entrepreneurs in the space. To get an answer on what is driving investor enthusiasm behind no-code, we reached out to a handful of investors who have explored the space:
- Laela Sturdy, general partner at CapitalG
- Raviraj Jain, partner at Lightspeed
- Darian Shirazi, general partner at Gradient Ventures
- S. Somasegar, managing director at Madrona Venture Group
- And, closing notes from an interview with Rajeev Batra from Mayfield
As usual, we’re going to pull out some of the key trends and themes we identified from the group’s collected answers, after which we’ll share their responses at length, edited lightly for clarity and formatting.
Trends, themes
Our investor participants agreed that low-code/no-code apps haven’t reached their peak potential, but there was some disagreement in how universal their appeal will prove to various industries. “Every trend is overhyped in some way. Low-code/no-code apps hold a lot of promise in some areas but not all,” Lightspeed’s Raviraj Jain told us.
Meanwhile, Gradient’s Darian Shirazi said “any and all” industries could benefit from increased no-code/low-code toolsets. We can see it either way, frankly.
CapitalG’s Laela Sturdy says the breadth of appeal boils down to finding which industries face the biggest supply constraints of technical talent.
“There just isn’t enough IT talent out there to meet demand, and issues like security and maintenance take up most of the IT department’s time. If business users want to create new systems, they have to wait months or in most cases, years, to see their needs met,” she wrote. “No-code changes the equation because it empowers business users to take change into their own hands and to accomplish goals themselves.”
Mayfield’s Rajeev Batra agreed, saying it would be cool “to see not twenty million developers [building] really cool software but two, three hundred million people developing really cool, interesting software.” If that winds up being the case, the sheer number of monthly-actives in the no and low-code spaces would imply a huge revenue base for the startup category.
That makes a wager on platforms in the space somewhat obvious.
And those bets are being placed. On the topic of valuations and developer interest, our collected interviewees were largely bullish on startup prices (competitive) and VC demand (strong) when it comes to no-code fundraising today.
Sturdy added that the number of early-stage companies in the category “are being funded at an accelerating pace,” noting that her firm is “excitedly watching this young cohort of emerging no-code companies and intend to invest in the trend for years to come.” So, we’re not about to run short of fodder for more Series A and B rounds in the space.
Taken as a whole, like it or not, the no and low-code startup trend appears firm from both a market-fit perspective and from the perspective of investor interest. Now, the rest of the notes.
Laela Sturdy, general partner, CapitalG
We’ve seen some skepticism in the market that the low-code/no-code trend has earned its current hype, or product category. Do you agree that the product trend is overhyped, or misclassified?
I don’t think it’s over-hyped, but I believe it’s often misunderstood. No code/low code has been around for a long time. Many of us have been using Microsoft Excel as a low-code tool for decades, but the market has caught fire recently due to an increase in applicable use cases and a ton of innovation in the capabilities of these new low-code/no-code platforms, specifically around their ease of use, the level and type of abstractions they can perform and their extensibility/connectivity into other parts of a company’s tech stack. On the demand side, the need for digital transformation is at an all-time high and cannot be met with incumbent tech platforms, especially given the shortage of technical workers. Low-code/no-code tools have stepped in to fill this void by enabling knowledge workers — who are 10x more populous than technical workers — to configure software without having to code. This has the potential to save significant time and money and to enable end-to-end digital experiences inside of enterprises faster.
What other opportunities does the proliferation of low-code/no-code programs open up when it comes to technical and non-technical folks working more closely together?
This is where things get exciting. If you look at large businesses today, IT departments and business units are perpetually out of alignment because IT teams are resource constrained and unable to address core business needs quickly enough. There just isn’t enough IT talent out there to meet demand, and issues like security and maintenance take up most of the IT department’s time. If business users want to create new systems, they have to wait months or in most cases years to see their needs met. No-code changes the equation because it empowers business users to take change into their own hands and to accomplish goals themselves. The rapid state of digital transformation — which has only been expedited by the pandemic — requires more business logic to be encoded into automations and applications. No code is making this transition possible for many enterprises.
Powered by WPeMatico
Eliminate DevOps waste with Japanese management practices
Co-founder and CTO of Rookout, Liran is an award-winning cybersecurity practitioner and writer who advocates for modern software methodologies.
Across the board, industries need to embrace modern workflows to keep up with the speed of startups. And out of all the various methodologies, I find the “lean methodology” to be the most intriguing of them all. It’s a unique combination of pragmatism and a higher purpose.
Lean methodology descends directly from the Toyota Production Systems (TPS), which is based on a philosophy of eliminating waste to achieve efficiency in processes. It relies heavily on the mindset of “just-in-time,” making only “what is needed when needed, and in the amount needed.” In software development, this means only developing the features your clients need, and only when they need them.
To emphasize the point and stir some creative juices, let’s look at the Japanese concepts of muda, mura and muri, and how this applies to being lean when we are building and shipping software.
Muda, mura and muri
Muda is the “waste” we are working to remove that is directly hurting efficiency. Waste is any activity that doesn’t create value, in the form of the products and services we offer. As every engineer knows, spending half the day in meetings is a painful waste of time.
Mura is “unevenness,” referring to any variance in the process itself or the output generated. In software development, “mura” causes unpredictability that makes it impossible to embrace a “just-in-time” mindset. If the quality of a new upcoming feature is uncertain, then additional time and resources will have to be reserved for quality assurance and bug-fixing efforts. It’s better to know upfront what you are going to get, how long it will take and what the cost will be.
Muri is “overburden,” which happens when we demand the unreasonable from our team, tools and processes. If we want to deliver a specific feature just-in-time, then we must allocate the appropriate time and resources. Giving our engineering teams too many simultaneous tasks, or failing to give them the tools necessary to succeed, will only lead to disappointment in time, quantity, quality or cost.
Forms of waste
Diving deeper into muda — what I consider the cardinal sin of lean methodology — here are the forms of waste we should always be on the lookout for:
- Overproduction – Producing more than is needed, or before it is required. Besides unneeded features, we often over-allocate computing resources, especially in non-cloud environments.
Powered by WPeMatico
Merico raises $4.1M for its developer analytics platform
Merico, a startup that gives companies deeper insights into their developers’ productivity and code quality, today announced that it has raised a $4.1 million seed round led by GGV Capital, with participation from Legend Star and previous investor Polychain Capital. The company was originally funded by the open source-centric firm OSS Capital.
“The mission of Merico is to empower every developer to build better and realize more value. We are excited that GGV Capital and our other investors see the importance of bringing more useful data to the software development process,” said Merico founder and CEO Jinglei Ren. “In today’s world, enabling remote contribution is more important than ever, and we at Merico are excited to continue our pursuit of bringing the most insightful and practical metrics to support both enterprise and open-source software teams.”
Merico head of business development Maxim Wheatley tells me that the company plans to use the new funding to enhance and expand its existing technology and marketing efforts. As a remote-first startup, Merico already has team members in the U.S., Brazil, France, Canada, India and China.
“In keeping with our roots and mission in open source, we will be focusing some of these new resources to engage more collaboratively with open-source foundations, contributors and maintainers,” he added.
The idea behind Merico was born out of two key observations, Wheatley said. First of all, the team wanted to create a better way to analyze developer productivity and the quality of the code they generate. Some companies still simply use the number of lines of code generated by a developer to allocate bonuses for their teams, for example, which isn’t a great metric by any means. In addition, the team also wanted to find ways to better allocate income and recognition to the community members of open-source projects based on the quality of their contributions.
The company’s tool is systems agnostic because it bases its analysis on the codebase and workflow tools instead of looking at lines of codes or commit counts, for example.
“Merico evaluates the actual code, in addition to related processes, and places productivity in the context of quality and impact,” said Merico CTO Hezheng Yin . “In this process, we evaluate impact leveraging dependency relationships and examine fundamental indicators of quality including bug density, redundancy, modularity, test-coverage, documentation-coverage, code-smell and more. By compiling these signals into a single point of truth, Merico can determine the quality and the productivity of a developer or a team in a manner that more accurately reflects the nature of the work.”
As of now, Merico supports code written in Java, JavaScript (Vue.js and React.js), TypeScript, Go, C, C++, Ruby and Python, with support for other languages coming later.
“Merico’s technology delivers the most advanced code analytics that we’ve seen on the market,” said GGV’s Jenny Lee . “With the Merico team, we saw an opportunity to empower the organizations of tomorrow with insight. In this era of remote transformation, there’s never been a more critical time to bring this visibility to the enterprise and to open source; we can’t wait to see how this technology drives innovation in both technology and management.”
Powered by WPeMatico
The great stink in software pipelines
It’s the summer of 1858. London. The River Thames is overflowing with the smell of human and industrial waste. The exceptionally hot summer months have exacerbated the problem. But this did not just happen overnight. Failure to upkeep an aging sewer system and a growing population that used it contributed to a powder keg of effluent, bringing about cholera outbreaks and shrouding the city in a smell that would not go away.
To this day, Londoners still speak of the Great Stink. Recurring cholera infections led to the dawn of the field of epidemiology, a subject in which we have all recently become amateur enthusiasts.
Fast forward to 2020 and you’ll see that modern software pipelines face a similar “Great Stink” due, in no small part, to the vast adoption of continuous integration (CI), the practice of merging all developers’ working copies into a shared mainline several times a day, and continuous delivery (CD), the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way.
While contemporary software failures won’t spread disease or emit the rancid smells of the past, they certainly reek of devastation, rendering billions of dollars lost and millions of developer hours wasted each year.
This kind of waste is antithetical to the intent of CI/CD. Everyone is employing CI/CD to accelerate software delivery; yet the ever-growing backlog of intermittent and sporadic test failures is doing the exact opposite. It’s become a growing sludge that is constantly being fed with failures faster than can be resolved. This backlog must be cleared to get CI/CD pipelines back to their full capabilities.
What value is there in a system that, in an effort to accelerate software delivery, knowingly leaves a backlog of bugs that does the exact opposite? We did not arrive at these practices by accident, and its practitioners are neither lazy nor incompetent so; how did we get here and what can we do to temper modern software development’s Great Stink?
Ticking time bombs
Powered by WPeMatico
Implement DevSecOps to transform your business to IT-as-code
Michael Fraser is an Air Force Veteran and co-founder of Refactr, a DevSecOps automation platform that helps tech teams modernize towards IT-as-code.
Conduct an online search and you’ll find close to one million websites offering their own definition of DevSecOps.
Why is it that domain experts and practitioners alike continue to iterate on analogous definitions? Likely, it’s because they’re all correct. DevSecOps is a union between culture, practice and tools providing continuous delivery to the end user. It’s an attitude; a commitment to baking security into the engineering process. It’s a practice; one that prioritizes processes that deliver functionality and speed without sacrificing security or test rigor. Finally, it’s a combination of automation tools; correctly pieced together, they increase business agility.
The goal of DevSecOps is to reach a future state where software defines everything. To get to this state, businesses must realize the DevSecOps mindset across every tech team, implement work processes that encourage cross-organizational collaboration, and leverage automation tools, such as for infrastructure, configuration management and security. To make the process repeatable and scalable, businesses must plug their solution into CI/CD pipelines, which remove manual errors, standardize deployments and accelerate product iterations. Completing this process, everything becomes code. I refer to this destination as “IT-as-code.”
Why is DevSecOps important?
Whichever way you cut it, DevSecOps, as a culture, practice or combination of tools, is of increasing importance. Particularly these days, with more consumers and businesses leaning on digital, enterprises find themselves in the irrefutable position of delivering with speed and scale. Digital transformation that would’ve taken years, or at the very least would’ve undergone a period of premeditation, is now urgent and compressed into a matter of months.
The keys to a successful DevSecOps program
Security and operations are a part of this new shift to IT, not just software delivery: A DevSecOps program succeeds when everyone, from security, to operations, to development, is not only part of the technical team but able to share information for repeatable use. Security, often seen as a blocker, will uphold the “secure by design” principle by automating security code testing and reviews, and educating engineers on secure design best practices. Operations, typically reactive to development, can troubleshoot incongruent merges between engineering and production proactively. However, currently, businesses are only familiar with utilizing automation for software delivery. They don’t know what automation means for security or operations. Figuring out how to apply the same methodology throughout the whole program and therefore the whole business is critical for success.
Powered by WPeMatico
Data startup Axiom secures $4M from Crane Venture Partners, emerges from stealth
Axiom, a startup that helps companies deal with their internal data, has secured a new $4 million seed round led by U.K.-based Crane Venture Partners, with participation from LocalGlobe, Fly VC and Mango Capital. Notable angel investors include former Xamarin founder and current GitHub CEO Nat Friedman and Heroku co-founder Adam Wiggins. The company is also emerging from a relative stealth mode to reveal that is has now raised $7 million in funding since it was founded in 2017.
The company says it is also launching with an enterprise-grade solution to manage and analyze machine data “at any scale, across any type of infrastructure.” Axiom gives DevOps teams a cloud-native, enterprise-grade solution to store and query their data all the time in one interface — without the overhead of maintaining and scaling data infrastructure.
DevOps teams have spent a great deal of time and money managing their infrastructure, but often without being able to own and analyze their machine data. Despite all the tools at hand, managing and analyzing critical data has been difficult, slow and resource-intensive, taking up far too much money and time for organizations. This is what Axiom is addressing with its platform to manage machine data and surface insights, more cheaply, they say, than other solutions.
Co-founder and CEO Neil Jagdish Patel told TechCrunch: “DevOps teams are stuck under the pressure of that, because it’s up to them to deliver a solution to that problem. And the solutions that existed are quite, well, they’re very complex. They’re very expensive to run and time-consuming. So with Axiom, our goal is to try and reduce the time to solve data problems, but also allow businesses to store more data to query at whenever they want.”
Why did they work with Crane? “We needed to figure out how enterprise sales work and how to take this product to market in a way that makes sense for the people who need it. We spoke to different investors, but when I sat down with Crane they just understood where we were. They have this razor-sharp focus on how they get you to market and how you make sure your sales process and marketing is a success. It’s been beneficial to us as were three engineers, so you need that,” said Patel.
Commenting, Scott Sage, founder and partner at Crane Venture Partners added: “Neil, Seif and Gord are a proven team that have created successful products that millions of developers use. We are proud to invest in Axiom to allow them to build a business helping DevOps teams turn logging challenges from a resource-intense problem to a business advantage.”
Axiom co-founders Neil Jagdish Patel, Seif Lotfy and Gord Allott previously created Xamarin Insights that enabled developers to monitor and analyse mobile app performance in real time for Xamarin, the open-source cross-platform app development framework. Xamarin was acquired by Microsoft for between $400 and $500 million in 2016. Before working at Xamarin, the co-founders also worked together at Canonical, the private commercial company behind the Ubuntu Project.
Powered by WPeMatico
Atlassian launches new DevOps features
Atlassian today launched a slew of DevOps-centric updates to a variety of its services, ranging from Bitbucket Cloud and Pipelines to Jira and others. While it’s quite a grab-bag of announcements, the overall idea behind them is to make it easier for teams to collaborate across functions as companies adopt DevOps as their development practice of choice.
“I’ve seen a lot of these tech companies go through their agile and DevOps transformations over the years,” Tiffany To, the head of agile and DevOps solutions at Atlassian told me. “Everyone wants the benefits of DevOps, but — we know it — it gets complicated when we mix these teams together, we add all these tools. As we’ve talked with a lot of our users, for them to succeed in DevOps, they actually need a lot more than just the toolset. They have to enable the teams. And so that’s what a lot of these features are focused on.”
As To stressed, the company also worked with several ecosystem partners, for example, to extend the automation features in Jira Software Cloud, which can now also be triggered by commits and pull requests in GitHub, GitLab and other code repositories that are integrated into Jira Software Cloud. “Now you get these really nice integrations for DevOps where we are enabling these developers to not spend time updating the issues,” To noted.
Indeed, a lot of the announcements focus on integrations with third-party tools. This, To said, is meant to allow Atlassian to meet developers where they are. If your code editor of choice is VS Code, for example, you can now try Atlassian’s now VS Code extension, which brings your task like from Jira Software Cloud to the editor, as well as a code review experience and CI/CD tracking from Bitbucket Pipelines.
Also new is the “Your Work” dashboard in Bitbucket Cloud, which can now show you all of your assigned Jira issues, as well as Code Insights in Bitbucket Cloud. Code Insights features integrations with Mabl for test automation, Sentry for monitoring and Snyk for finding security vulnerabilities. These integrations were built on top of an open API, so teams can build their own integrations, too.
“There’s a really important trend to shift left. How do we remove the bugs and the security issues earlier in that dev cycle, because it costs more to fix it later,” said To. “You need to move that whole detection process much earlier in the software lifecycle.”
Jira Service Desk Cloud is getting a new Risk Management Engine that can score the risk of changes and auto-approve low-risk ones, as well as a new change management view to streamline the approval process.
Finally, there is new Opsgenie and Bitbucket Cloud integration that centralizes alerts and promises to filter out the noise, as well as a nice incident investigation dashboard to help teams take a look at the last deployment that happened before the incident occurred.
“The reason why you need all these little features is that as you stitch together a very large number of tools […], there is just lots of these friction points,” said To. “And so there is this balance of, if you bought a single toolchain, all from one vendor, you would have fewer of these friction points, but then you don’t get to choose best of breed. Our mission is to enable you to pick the best tools because it’s not one-size-fits-all.”
Powered by WPeMatico