Articles

There were mixed reactions on Thursday morning when Adobe announced it had acquired Figma.

Excited press releases extolling the benefits of the “collaboration” followed the news. Dylan Field, founder and CEO of Figma, said: “There is a huge opportunity for us to accelerate the growth and innovation of the Figma platform with access to Adobe’s technology…”

The reaction from the design community has been a little less enthusiastic.

The problem for the design industry is that we’ve been here before. The acquisition of Macromedia followed a period in which Adobe tried to compete, failed to update its legacy code, lost the battle, and purchased the victor. You only need to look at the number of former Macromedia products in Adobe’s stable (zero) to see where Figma’s heading.

Figma has grown faster than any of its rivals in the last eight years. It is, of course, easier to grow when you start at zero. But there’s no denying Figma is a well-managed business and probably a good investment — if not worth the $20bn that Adobe reportedly paid.

Figma’s technology will give Adobe a leg-up in the collaborative design stakes, where it is clearly lacking. And Adobe’s resources will iron out some of the kinks in Figma, especially around typography, which is, if we’re honest, a bit hacky in places.

Adobe will provide a good home (we hope) for the Figma team, who will have the opportunity for career advancement in a much wider pool of development teams.

And, of course, Figma’s annual revenue will begin to trickle into Adobe’s vault — although it may be some time before it makes a dent in that $20bn hole.

But Adobe didn’t buy Figma for its business model, collaborative technology, team, or revenue stream. Adobe bought Figma’s users, all four million of them.

Adobe‘s approach to design software is upselling. It lures you in with free apps, and when you’re engaged, it integrates them with other parts of its ecosystem until suddenly, without meaning to, you’ve agreed to a Creative Cloud subscription.

Adobe was losing customers to a competitor. And more importantly, due to Figma’s free-use approach for individuals, it was losing young customers to a competitor. If it hadn’t bought Figma, Adobe would have needed to invest heavily in its own products while providing them to freelancers for free; that isn’t viable for a company with as many commitments as Adobe.

Yes, it is entirely accurate to say that competition drives innovation, and with fewer competing apps, there is less need for companies like Adobe to build high-quality, reliable products. However, it is also true to say that a lack of competition creates opportunities for new apps.

Somewhere out there, in a dorm room, or a basement, or on a kitchen table, someone is working on Adobe’s next big acquisition. It’s probably an AR design app; we need a few more of those.

For Figma, the next 12 months will be bright as Adobe works to retain the customers it’s bought. Within five years, you’ll probably need an Adobe Fonts subscription and a Photoshop plugin to use Figma. In ten years, it will be stored in a code archive next to Freehand.

Some designers will turn to Sketch; others will turn to Affinity; some will shrug and keep using Figma; others will shrug and keep using XD.

If an app is intrinsic to your design work, it’s probably time to switch apps. Your skills are transferable. I’ve switched apps many times; some I loved, some I just needed. I’ve never encountered an app that improved my work, although plenty have improved my mood while working.

Figma took a great approach and will continue to be great until it isn’t. Tools come and go, Adobe’s acquisitions team, it appears, is eternal.

 

 

Featured image uses photos by Afrika ufundi, Andrea Piacquadio, Andrea Piacquadio, Anna Tarazevich, cottonbro, fauxels, Ketut Subiyanto, Mikhail Nilov, Moose Photos, Pavel Danilyuk, Pavel Danilyuk, Polina Tankilevitch, Tima Miroshnichenko.

Source

The post Adobe Has Acquired You first appeared on Webdesigner Depot.

Source de l’article sur Webdesignerdepot

As more and more organizations making the shift to cloud-native technologies, Kubernetes has become the de facto choice to orchestrate container-based applications. As applications grow in size, the number of microservices increases and so does the data they process. Hence, handling data, especially sensitive data becomes critical. Out of the box, Kubernetes supports « Secrets » objects to store sensitive information — like passwords, tokens, ssh keys, and so on — securely.

Kubernetes secret eliminates the need to hard-code sensitive data in the application code. Secrets provide this sensitive information as data mount or expose them as environment variables.

Source de l’article sur DZONE


As the number of services grows in an organization, the problem of secret management only gets worse. Between Zero Trust and the emergence of microservices, handling secrets such as tokens, credentials, and keys has become an increasingly challenging task. That’s where a solution like HashiCorp’s Vault can help organizations solve their secret management woes.

Although there are secret management tools native to each cloud provider, using these solutions locks you in with a specific cloud provider. Vault, on the other hand, is open source and portable.

Source de l’article sur DZONE

As we all know the Cloud-based systems are becoming the most popular architecture in the software engineering world, and the most famous and beloved Cloud platform among developers is Spring Cloud.

Spring Cloud has some important features which are given in the following parts and the feature part does a specific job:

Source de l’article sur DZONE

This week, we take a look at API vulnerabilities in HashiCorp Vault, Azure App Services, and more. There is also an introductory video on finding information disclosure in JSON and XML API responses, and another cheat sheet and a webinar on OWASP API Security Top 10.

Vulnerability: HashiCorp Vault

Felix Wilhelm from Google’s Project Zero has written a very detailed write-up on an authentication bypass he found in the Amazon Web Services (AWS) and Google Cloud Platform (GCP) integration of HashiCorp Vault. As a central storage of credentials, Vault makes an attractive target for attackers, and therefore a vulnerability in it is also very bad news. Looking for the silver linings, this attack was definitely quite advanced, and thus not easily exploitable.

Source de l’article sur DZONE

In part one of this series on Best Practices for Building and Designing Containers for Kubernetes, we looked at how to separate config from code in Kubernetes and why you need to do that. Specifically, we examined how config maps and environment variables are defined and configured. In this post, we continue that important discussion with a look at secrets management, what secrets are, and how you manage them.

Managing Public Configuration Information in Kubernetes

Not all configuration information is safe to keep out in the “public” and many, if not most, Kubernetes-hosted workloads need usernames/passwords, tokens, keys or other private information to securely connect to other services. There are a variety of options worth exploring here, each with its own set of positives and negatives.

Source de l’article sur DZONE