Junilu Lacar wrote:
Al Razor wrote:I work in an enterprise like that and this company moved to cloud (AWS) a few years ago. I've seen how this change affected more than just technical side of things. This is the reason why I mentioned it in my original message.
Maybe mentioning that then could have brought us to this point much earlier. Were the effects of the change for the better or worse? What were some of those effects, specifically?
Junilu Lacar wrote:
Al Razor wrote:Quite surprising to see that book almost doesn't cover it.
That's quite the understatement considering the single occurrence of the word "cloud" in the book is buried in that one paragraph I quoted.
I think this quote from https://www.theguardian.com/deloitte-public-sector-in-a-digital-world/2020/apr/06/the-switch-to-cloud-how-public-services-are-becoming-more-agile-and-innovative nicely outlines some of the points:
And therein lies the difference, I think, in the idea of agility that Bob writes about in the book and the kind of agility you seem to be thinking about. But let's wait for Bob to chime in on this, maybe I've got it all wrong, which wouldn't be at all surprising.
Junilu Lacar wrote:In an enterprise where thousands (yes, that many) of different applications are deployed on a worldwide network of servers in various data centers, even upgrading from one version of a server platform to the a new version can be quite the undertaking. In one company I worked for, it would take at least a year of preparation and coordination. In one company I've consulted for, they're still a ways away in their now years-long effort to move off of their mainframe. There are a lot of things getting in their way, not the least of which is the huge amount of technical debt (translated, per Ward Cunningham's definition, to "lack of understanding") in their current mainframe systems.
Al Razor wrote:You can't seriously compare moving to cloud to a change of one of the technologies at the very least because it affects your whole infrastructure.
Junilu Lacar wrote:I'm trying to say exactly what I asked: what's the connection between a change like going to the cloud and agility? Change is always there. Enterprises migrate to new technologies all the time, developers have to learn and adapt to new technologies all the time. How is moving to the cloud any different from say moving from DB2 to Oracle or from WAS to Nginx or Node, or Maven to Gradle, or technology stack X to technology stack Y. What do you see is so special about moving to the cloud?
I do have the book, by the way, and there's but one glancing mention of "cloud" in it in Chapter 7 "Software Craftsmanship" written by Sandro Mancuso, who was also a guest author here in the past.
Moving to the cloud not only saves time on purchasing and managing physical environments, it also opens up access to a suite of software on the internet as a service. It is far quicker to amend these to an organisation’s requirements, rather than have software written from scratch. “Traditional procurement and development processes could take several months, by which time an organisation’s needs may have moved on,” Appleton-Norman explains.
By moving to the cloud, Appleton-Norman has found that Deloitte’s public sector clients are able to embrace the pioneering attitude found at exciting startups where new ideas can be tested at breakneck speed.
“The cloud empowers companies to be part of the new wave of fail-fast, agile development,” she says. “With the cloud you can leverage the necessary storage capacity very quickly and there are usually software packages you can try out and adapt that already work on that platform. The real beauty for organisations is that the technology enables them to get pilot projects set up really quickly. If they work, it’s great, if they don’t, they can be shut down immediately with no extra expense incurred.”
Junilu Lacar wrote:@Al. what's the correlation between being agile and becoming cloud-oriented? I'm not seeing the connection...
Junilu Lacar wrote:I personally think that teams that have already moved from Java to Kotlin will stay in Kotlin until there's a compelling reason to switch back to Java. Maybe the same thing goes for teams that haven't made the switch to Kotlin yet (I mean that they'll stick with Java unless there's a compelling reason to go to Kotlin). I think teams that are doing Android development are more likely to make the switch to Kotlin though, since it has the backing from Google and the Android team. It's expressive and in many ways more enjoyable to code in than Java.
Junilu Lacar wrote:
Al Razor wrote:What do you think about Kotlin position when Java 14 becomes more available (OpenJDK released)?
Are you trying to imply that Kotlin would somehow become less relevant because of new features introduced in Java 14? Which specific features do you have in mind, if any?
I think that Kotlin will continue to evolve as more people use it. That path of evolution may be influenced by new additions and changes to the Java language and standard library but in my opinion, there's about as much pressure to change coming from Kotlin to Java, if not more. For example, Kotlin already supports multiline strings just as Groovy does whereas text blocks are still a preview mode feature in Java 14.
Guy deLyonesse wrote:You're setting an awful lot of request attributes. Are you using a new instance of the browser between testing sessions?