Debunking the top 8 myths about cloud: what’s fact vs fiction?

[#1]

Mythbusters may be off the air, but we’re keeping their legacy alive by setting the record straight about cloud. Could an out-of-date belief be holding your team back?

Cloud continues to improve at hyper-speed, so concerns that were valid just six months ago could be merely myths today.

What’s truth and what’s myth when it comes to cloud? We’ve debunked some of the most commonly held misconceptions.

Go ahead and jump right in based on what matters most to you:

• Security & Compliance
• Performance
• Apps
• Data Management
• Change Management
• Admin Roles & Responsibilities
• Customization
• Enterprise Scalability

Which myth surprised you the most? Do any of your teammates need a refresher? To learn more about cloud myths, visit our Mythbusting hub (and share it with your team!).

[Jimmy Seddon]

Thanks for sharing this @Elizabeth Howden!

Also thank you to the Cloud Migration team that included my quote in the Admin Roles & Responsibilities myth!  I 100% agree that moving to Cloud was an extremely positive experience and I'd make the move again in a heartbeat.

 

[Fazila Ashraf]

Thank you @Elizabeth Howden  ! This did give me more clarity.. 

But one of the biggest blocker for my team is that we have used hundreds of scriptrunner scripted customization and was told that we will have to rewrite all the scripts for the cloud version of scriptrunner :( 

[Brant Schroeder]

@Elizabeth Howden Thanks for the information.  I think this is great information about the cloud in general.  Is there information that is specific to the myths of Atlassian Server vs Atlassian Cloud or a good resource that compares the two product (Pros and Cons)?

[Soumyadeep Mandal]

Hi @Elizabeth Howden ,

Thanks for sharing this information with the available links!

These are some nice myths about the cloud and you are absolutely right!

[Elizabeth Howden]

@Brant Schroeder Here are two good resources for comparing server and cloud:

• The biggest difference between server and cloud 
• https://www.atlassian.com/migration/cloud/explore (scroll down to the platform and product comparisons) 

[Wolfram Webers]

If you're so dedicated being a cloud-first-company, why the heck I cannot login into my account anymore? (Endless redirects from "id.atlassian.com" to "my.atlassian.com" and back). I cannot even contact the support because the support form demands to be able to login into my account: catch 22!

So yeah. Right now I use your on-prem services and am happy with it. But this behaviour is not really building up any trust into the pure cloud based solution...

[Diego Agulló]

For us, there's lots of perceived blockers to migrate. Among them, the most important are:

• Hundreds of ScriptRunner scripts/postfunctions/listeners which would need to be reviewed and rewritten
• Data localisation issues because of regulatory compliance
• Security dependant on a third party (Atlassian) instead of our own in-house teams

I would love some debunking on these things. Will Atlassian work with its partners and marketplace vendors to ease the migration for plugin configurations? Will the admins be able to select the physical localisation of their company's data? Is there some way to not delegate authentication to Atlassian?

[Vincent DEBOSSE]

Cloud means internet connectivity is required.

My instances are running in protected networks are that physically disconnected from Internet, for security and confidentiality.

That is quite a blocker, unless you give away the cloud version to work on-premise, but that would be just like releasing server again.

[Wolfram Webers]

An on the top of it we're encouraged to use Atlassian Access "to have full control" of our data. Yeah, and some Atlassian data center admin (or one of Atlassians sub-contrator in whatever country) will have full access to my users credentials. Cool thinking... I want to use my OWN IdP and my OWN policy based access control, hosted in my OWN datacenter.

Make sure NO WHATSOEVER admin has ANY chance to get access to my data, e.g. because it fully encrypted where only I have access to the keys (of course with a strength NO US governmental creep could crack). Then, and only then we can talk cloud solutions. 

[Daniel Ebers]

While there, indeed, are advantages that sound very tempting I hope we can get customizations back up running. These are mostly Script Runner listeners, scripted fields - and what worries me a bit: behaviours. Probably a different approach must be found.

As for the mythbusters page: nice one - I like that common myths are addressed and the explanations sound comprehensible to me. Keep up the good work!

[Daniel Eads]

Hi @Wolfram Webers , I wanted to reach out about your issue logging in:

why the heck I cannot login into my account anymore? (Endless redirects from "id.atlassian.com" to "my.atlassian.com" and back)

Do you happen to be using Brave browser? This is a common issue we're seeing currently with the Shields function - if that's your browser, you can follow the steps here to unstick the login flow.

If not, would you be able to let me know which browser you're using, on which operating system, and if you've got any adblock/cookie-blocking extensions enabled? I'd like to try and replicate the issue you're seeing to help unstick the login for you.

Thanks,
Daniel | Atlassian Support

[Elizabeth Howden]

Hi @Diego Agulló - Thank you for taking the time to share your feedback on blockers for migrations. I wanted to share some resources in response to a few of your questions: 

• App Migration Paths: we are actively investing in making app migration easier. Here's a resource that documents available app migration paths and here's information on using the App Assessment functionality in the Jira & Confluence Cloud Migration Assistants 
• Data residency: Atlassian documentation on cloud data hosting regions and data management update on Atlassian's Cloud Roadmap

[PJ Wysota]

What I wrote in 7 (non-user’s) stories on (not only) Jira governance - choice between on-premise and cloud was recently not about the money, nor it should be about core functionalities and core business requirements. Therefore I appreciate this debunk article, as it only proves a lot has changed in recent years in thinking about Cloud offering.

I would also go against those implementations that are running rather on script runner than Jira itself. Well, You wanted custom dev - you got custom dev. That is YOUR tech debt. IMHO 97%-98% of functionalities from Jira and Confluence, regardless if this is on-premise, or Cloudy you can achieve with config, and marketplace add-ons. Script are needed for "last mile" tuning, or - as "cheap" replacement for other apps, better suited for specific use case.

However there are few points from governance point of view:

1. Change/Release Control - although article is fully right on aspects it covers (like performance control, which is definitely better with Atlassian, than with thousands of distributed customers), But it misses one crucial point - Control over release policies and timeframes is to assure rather compliance, and smooth operations than anything else. If we are not going for newer version is rather because we cannot pause/stop or in extreme cases (when business process is so dependent on older functionalities it cannot run on newer) retire some of obsolete stuff.

2. Test environments - (yup, I know Atlassian is working on those) - so far Cloud offers none option for separating environments to allow tests on non-prod. And even taking into account most liberal approach - that majority of changes can be tested in separated projects in prod-environments (all business config changes, automation changes etc.) there is still at least one use-case that lit the red light - installing new add-ons/upgrading add-ons. This, regardless of how restrictive Atlassian release policies for ad-ons are is always a bit of gamble in tailored, customized *different apps, configs, etc.) environments.

3. Data Security - Financial, Personal, any Sensitive Data restriction policies will be highly targeting Cloud as "unsecure". Again - Atlassian is working on solutions like "data storage zones" preferable when setting accounts - still it will work for core products - how about add-ons? not all vendors will keep several data locations = one for US< one for EU, one for Russia, one for China, and 2-3 others for rest of the world. 

Of course - for many customers these are not a showstoppers - as either they will disregard them, or anyway - pick up Data Center. Still I assume c.a. 5% of customers will leave due to one of above points plus costs of DC (they cannot afford it).

[Wolfram Webers]

@PJ Wysota About your 3rd point:

But you know that the "location" doesn't matter according the CloudAct? If not I recommend you reading the summary of the DOJ.

https://www.justice.gov/dag/cloudact

I read this all the time: Yeah, calm down, we have a data center in EU.

Well, but as long as there's an american company involved in the ownership (directly or indirectly) operatering the data the CloudAct is applicable. And that's pretty much it with outside access to the data. Sure, bigger cloud players argue that the US creeps need to make the way through european legislative bureaucracy and respect the countries laws. But that's pretty much the weakest alibi as the european law got weakened more and more in this respect during the last years (if the US creeps even take care of that).

That means: You got sensitive data? Stay away of any non-european cloud solution and make sure no non-european company is involved at any stage in data operation. Otherwise, you could likewise use other cloud plattforms of countries like China or Russia. That makes no huge difference. They at least do not try to cover their data hunger in such bullshit like "Safe Habour" or "Privacy Shield".

Finally, why doesn't anyone ask this question: Why the heck are so many companies so keen to convince decision maker to go for cloud solutions? Quiet sure it's not because those cloud solution providers are humitarians and fighters for a better world, that's for sure.

[Wolfram Webers]

@Daniel Eads No, not using BRAVE browser. But for sure I use AdBlocking and 3rd party cookie blocking. Everything else would be unresponsible. However, I managed to solve it temporarily just to make sure Atlassian isn't drawing any many anymore as I'm done with them after this transition decision anyway. But thanks for your hints.

[Dharma Ramos]

@Fazila Ashraf @Diego Agulló I have the same concerns and I'm hoping Adaptavist will have some answers to the migration questions at their upcoming webinar. 
https://www.adaptavist.com/webinars/migrate-scriptrunner-for-jira-to-cloud

[Karlis Vesters]

I was fan of Atlassian, but this push to the cloud is something which makes review all the usage.

No control over upgrades in cloud! In one day our complex pipelines stops working and many people work is stopped. In my opinion pushing from matured system to much less matured system is very brave.

We will review possibilities to move to other alternatives which are more mature (e.g. Github vs. Bitbucket etc.) or even stay with server version like GitLab etc.

[M Amine]

Lately we have tried the Cloud for "some" advanced configuration and we found that Cloud features are by far behind Server/DC features. Here is why : 

• The User Experience cannot be customized as desired. In server we can use : Scriptrunner behaviors, Dynamic forms, SIL Live fields ...etc. Unfortunately, there is no Cloud app offering these features right now
• Postfunctions are all async in the Cloud. So the ordering of post functions is of no use. Besides, every issue update from the post function will not update the issue immediately. We have to hit the refresh button in order to see the update. Lately we had to demo this to a client and he didn't accepted and asked to migrate to Server
• Lately we had to use Insight AM Cloud and we have noticed that a lot of features are missing : Custom fields, User experience in the portal, Integration ...etc. 
• Data residency. We know there is a roadmap (https://www.atlassian.com/roadmap/cloud) for that, but a lot of things have to be done in order to be compatible with what clients ask for
• Domaine names are not customizable. Although there is a workaround for JSD users if they use refined app but Jira for agents will still use the *.atlassian.net
• ...

And these are showstoppers for us. I read a lot about Cloud vs Server, and all the paths for migrating the apps ...etc. But some basic features are not in the Cloud. How can we migrate to Cloud if we don't have these basic features? feel free to comment/help plz. 

[ABoerio]

Hi,

my management is not  against cloud in principle, and we already use several cloud services.

Our Confluence instance (server) is already located on a cloud server, and no more on a physical server within the company.

But we're always in control of every detail of the configuration and, even more, we can always decide to move it on a different cloud server, from a different supplier. Or we can decide to move it back on a phisical server located in the company, if we wish.

And the confluence server license we have bought is perpetual, that means that it'll be always possible to access to the pages and the content we've created or attached, even with no more need to pay anything to Atlassian.

We might decide to start using a different product, but we could have always access to what we created in Confluence, and not only to exported html or pdf versions. And it's likely to be what will happen in 2014, when we'll probably keep using Confluence server "as it will be", even with no more updates or support. Unless some big changes will happen in these three years. 

It's not the cloud concept itself, the problem, but the way Atlassian is implementing it.

It's the lost freedom, the real big concern. The content uploaded in Confluence Cloud will be only available when having (and obviously paying) an active subscription.  

Not talking about the current performances and options available in Confluence Cloud ...

Ciao, Andrea

[Ben Jacobs-Swearingen]

I cannot see many organizations buying into this unless you are willing to expose more details about your exact implementation of buzzwords like "zero trust"and explain how financials, PII and other sensitive classes of data currently being managed in offcloud deployments are going to be protected from, among others, your own cloud and service maintenance engineers.  It also isn't particularly enjoyable to contemplate access to our data being at the mercy of the health either of the Atlassian cloud itself or the network routes to said cloud.   $17k / year is way more than anyone needs to be paying in order to avoid such issues with, e.g., an offcloud ADC ecosystem.   

[Chris Jones]

hi, is it possible to restrict access to a Confluence or Jira Cloud instance to corporate PC's / devices only?

[Daniel Ebers]

Hi @Chris Jones

a restriction to only "your devices" is not possible. There would be the need to "mark" them somehow.
Instead, IP allowlisting is offered - access is then only possible by IPs you defined (defining a subnet is also possible).
The differentiation, in other words, would be the IP the device(s) is/are communicating your cloud site with - not a specific device.

[Daniel Eads]

@Chris Jones and @Daniel Ebers - as a further extension, you could consider using Atlassian Access to define security policies for your users. Access comes with conditional access policies and MFA options. If you have an Active Directory environment, you could configure Access to force authentication requests through Azure AD, where you can also apply a variety of conditional access policies and require hardware tokens for sign-in.

[Chris Jones]

thanks @Daniel Ebers I'm not sure IP allowlisting will be accepted by my org, it is quite easy to fake an IP address.

thanks also @Daniel Eads i guess we have to look at Access ...operating server behind the firewall was easy :)

Hopefully corp IT buy this and don't use as an excuse to force us back to !@#$%Point and TFS

[hammad solangi]

yes