Monday morning thoughts: cloud native
This weekend I discovered that one of my favourite online REPLs* – repl.it – has a new feature where you can build and publish a website on a repl.it subdomain:
*REPL: Read Evaluate Print Loop – an interactive language shell
I’ve used repl.it to explore language such as Clojure and Haskell, for various purposes, including the basis for a talk I gave at Manchester’s Lambda Lounge last year: “Discovering the beauty of recursion and pattern matching“:
A brief history
The new repl.it feature allows us to create a set of site artifacts, structured into directories, and have them hosted and served by repl.it’s infrastructure. I immediately thought of the options to host UI5 based demo apps. One page apps that are built with MVC, internationalisation and other features are necessarily complex in structure, in that there’s a lot of moving parts.
Quite a few years ago now I realised I could include XML view definitions and JavaScript controller scripts inside a single HTML file, using custom <script> tags. That extended to the use of JSBin, which has supported OpenUI5 for a while now (see “Small steps: OpenUI5 toolkit now in jsbin.com“), like in this layout example: http://jsbin.com/gatan/edit?html,js,output.
But the ability to create and serve UI5 apps, resplendent in their multi-artifact construction, still remained a desire, which was fulfilled with the advent of Plunkr, similar to JSBin. See this post from Denise Nepraunig for more details on UI5 with Plunkr: “Quickly tinker around with SAPUI5 examples“.
The online experience
But I digress. The new repl.it experience isn’t a revolution, more an evolution. It is, nevertheless, a very nice experience:
(Yes, this is a little UI5 app that was inspired by Meredith Hassett ‘s recent #APIFriday post “Building your Developer Profile – GitHub + UI5“).
I’m mindful of the tools I use with kids at the local Primary School and at Manchester CoderDojo. All the teaching I do, from Google Apps Script, to JavaScript, Scratch and even UI5, is done online. All the kids need is a laptop with enough battery, a connection to the wifi, and a browser.
This is a theme I’ve followed myself for a good few years, moving a long time ago “to the cloud” with Google productivity tools and latterly with ad hoc tools such as repl.it and of course the excellent SAP Web IDE. Some of you who interact with me on Twitter will know that I recently spent a whole two months using Chrome OS almost exclusively.
So the repl.it offering fits right into the online experience funnel I’m used to. In all that time with Chrome OS I never needed to reach to another laptop to do anything other than connect my running watch with the TomTom app that updated it with new “quick GPS” data (since then I’ve discovered that the new version of the app on my phone can do that now too). Of course, that doesn’t mean I’ve eschewed the command line – far from it. I’ve a Google Cloud Shell (free) which gives me a persistent and comfortable working shell environment, with all the amenities one would expect – tmux, vim, the Google Cloud SDK, the Google Cloud Functions emulator, ngrok and even the SAP Cloud Platform Neo environment SDK / console client (the latter two I installed separately, and I have my own configurations for tmux and vim of course).
Cloud native
So anyway, all this got me thinking, on my run this morning. We’re moving to cloud native architectures with the Cloud Platform offerings. Interaction is undeniably moving further and further online. That interaction extends to the architecture and development topics, the latter exemplified with the experience I’ve had thus far.
So I’m wondering: how do we define cloud native? What is the experience, and is it obvious when we see it? It’s clear to me, when I spend pretty much my entire day (modulo Outlook) online, in browser windows, where I find myself developing and deploying code, creating content, and configuring interconnectivity and routing with my Cloud Platform Technican‘s hat on.
Heck, I conceived, built and deployed the artifacts for, and wrote the content for the 10-part series on the SAP Cloud Platform Workflow service (“Discovering SCP Workflow“) all online.
With the advent and growth of SAP S/4HANA Cloud, and the PaaS and SaaS tools and facilities that are growing around it to support implementations, customisations and extensions, the cloud native experience is only going to grow. Yes, there are also processes and activities that require local installations of software, most notably for me is the ABAP Developer Tools in Eclipse and of course the venerable SAPGUI itself. But these appear as exceptions in my eyes, rather than the future normal.
What does cloud native mean to you? What defines it for development, for architecture, for our present and future enterprise solutions? I’d love to hear your thoughts via the comments section below.
Read more posts in this series here: Monday morning thoughts.
Cloud means less control. Less control of your system, less control of updates, less control on what is on your website.
So On-premise is still a good choice for me. What does that mean? Simply a hybrid of on-premise with added could functionality.
What's interesting to me is all the different languages that can and are being used. For awhile I think it is going to be open as to what we use. Eventually things have to slow down on language choices - simply for sustainable code. Even though it is fun - no one can learn it all.
Nice one!
Michelle
Nice response, thanks Michelle Crapo ! That's an interesting (and of course valid) perspective, although I have embraced the cloud as it gives me more control, not less. It also allows me to focus on what matters (the content) while letting folks who are much more skilled than I am look after the important stuff like resilience, backups and security.
Although this is not specifically about cloud vs on-premise, I often am reminded of a phase of the industrial revolution (perhaps one can say the world's Industry 1.0) which incidentally was born in this very region in Lancashire, around the city of Manchester. This phase saw the mills and factories running under their own steam - sometimes literally! Many were powered by their own power plant, whether that was a stream current powering a water wheel, or a coal-fired engine powering pulleys via beam and crank. I liken that to running one's own servers. Of course, it's far from being as simple as that, but I thought I'd highlight the analogy anyway.
You mention multiple languages, which is indeed an interesting topic. I don't think there can be a single language to rule them all (Wait, don't we have that already in the form of ABAP? -- Ed.) - what's important to me is that you can bring your own language that is suited to the problem at hand. What you write does open up another point, though, on sustainable code. I'm finding myself writing less code in contiguous blocks, and therefore in the same language, partly because of the nature of the disparate constellation of systems that form today's set of solutions. And because of the cloud (or, in this case, simply "the Internet"), this is a natural result of how we see things.
PS if one is ever in Manchester, I highly recommend visiting the Museum of Science & Technology, in particular my favourite section: The Power Hall.
Nope - not a debate on cloud vs. on-premise. Really I think I see more and more companies going to the cloud. There are valid arguments on each side.
Let's pretend for a second that you come from a small shop of developers - you add consultants as needed. So they bring their own tools. Oops, now you have to change something and they are long gone. Now you have to learn the language they wrote. Only the change is urgent and needs to be done within the hour. OK, a bit of a problem there.
I read, I learn, I read some more, and I find my head spinning. There are so many tools out there. Yes, there are some that are better for a task than others. But I might avoid them for a different reason. Some consultants also can't help you based on the language.
So - I am a 110% person behind learning the business not just the technical aspect. I was once asked what did I wanted to do technical or business side. I said both. I lean more towards the technical. Now with my head spinning on the languages, I do know the basics and can muck around in the business side. I think that piece is huge. Now add the effort to learn how to use the new toys - um I mean tools. I wonder how long I can be successful at both.
Take a deep breath. Count to 100 and know that as usual, I won't be the technical best. I will know a little of both. Or a bit more about both depending on what wins. Using limited languages or trying to use the best one. 🙂
As a customer of SAP, I will have to understand the basics of what is sent our way. Thinking about it - abap rules on the server side still. (For now) It's just the apps that will have to have a bit of a learning curve.
Brace yourself architects - this is not going to be an easy road. Balance the best vs. maintainable. Security is going to become even more important than it is now. Identity management, web servers, VPN... Again my head is starting to spin. I'm going to stop while I'm behind.
In other words - things are changing and changing very fast!
Michelle
Very sensible thoughts. And yes of course you're absolutely right, there are valid arguments for cloud and for on-premise.
To the picture you painted ("small shop of developers") - I for one wouldn't advocate allowing new consultants to bring their own language to an already existing project, nor to provide solutions in whatever languages they thought best.
To me, rigidity and flexibility describe a spectrum.
Towards the left-hand end, the development shop should define aspects such as how they do CI/CD, manage source code control, the review process, TDD, etc. Further along towards a more flexible part of the spectrum we see languages and protocols that are chosen, with the shop's input and direction, that are most suitable for the challenge at hand. Further along still are the tools such as editors. One might say that as long as the chosen editor has the facilities to comply with the shop's coding standards for the given language, to connect to and interact with the source code control system and to participate in the CI/CD process, then the actual editor itself, whether that's vim, SAP Web IDE, Microsoft VSCode, Atom or whatever is relevant, but less so.
One final note: "Brace yourself architects" - well said!
Extremely interesting exchange of ideas, thanks to you both for sharing your wisdom.
I've seen lots of ABAP developers struggling to embrace UI5, because it is so different to them. I think this is a whole new world for most people, with all these new technologies and languages to be embraced and it is not easy for many.
From a Community POV, I think that those who successfully handled this challenge are in a great position to help and mentor those who did not yet.
The challenge of going from ABAP to UI5 was my choice as a speaker on last Saturday's SAP Inside Track Ribeirão Preto (https://blogs.sap.com/2018/02/19/sap-inside-track-ribeirao-preto-first-edition-2018-sitrp/) and I saw people deeply interested in how I traveled this road myself.
You are doing something even better here, taking about the upcoming challenges and decisions everyone will face.
Congratulations and count on me!
Thanks Douglas. I definitely agree, to a certain extent. ABAP -> UI5 is a journey that has challenges, although one has to think about that comparison.
First, ABAP is a language, and it comes almost implicitly with a world around it that anyone freshly coming to ABAP will naturally take on board as part of that journey, for example the Data Dictionary and the concepts of the dynpro processor and the built-in debugging facilities, as well as the one-size-fits-all editor and source code control and deployment mechanisms. Not to mention a single, stable runtime environment!
Then you look at UI5, which is not even a language, it’s a toolkit that brings together multiple languages and notations (JavaScript, HTML, XML, JSON, and so on). It does have comfortable surroundings in the form of the SAP Web IDE, but you need to understand all the moving parts before you can work out where to fit yourself into that armchair. And multiple runtime environments with their nuanced differences and ever changing saids (did someone say "ES5->ES6->ES7?").
So I can understand the trepidation. But (and this is by no means false modesty) – if I can do it, so can others.
Then again, that’s only one direction. Perhaps we’ll see some early adopter “pure ABAP developers” going cloud native when the ABAP runtime becomes available on SCP. The programming model is perhaps the thing that joins us all together, and specifically one of the core technologies – the OData protocol, is one that can be the bridge between the two worlds, between the ABAPers who are comfortable with where they are now, and where they might want to be. OData is the lingua franca that can be and is largely spoken in “both camps”, or at both ends of the stack, in many scenarios.
So perhaps we see OData as a route to the cloud for some ABAPers too? A REST informed approach to integration smooths the way for OData, which in turn lays the foundation for metadata and annotations, which in turn leads to UI generation, as well as leading to a common approach to building and describing solutions, which leads to CDS, BOPF/BDL, and so on.
It’s like it’s all part of a big plan!
Random thoughts, I know, but there you go.
Hi DJ,
Yes, you are absolutely right on point.
I agree UI5 is not a language like ABAP, but rather a set of technologies including the JavaScript language. This is part of what makes it difficult for ABAP developers to learn it. In fact, I am still learning, even after successfully building some UI5 apps from scratch.
I can clearly see the value of using OData, CDS, and annotations to build better models to be used on the UI5 layer and also agree that it is something very useful to be done.
I am sure lots of people wants to step into new technologies and making it possible, or easier to them is something that really motivates when, for example, I think about what kind of session should I propose when I go to a SIT event and have the opportunity to share some experiences.
Thank you for your wisdom!
Best wishes,
Douglas
“What does cloud native mean to you?” That’s a nice question, and it reminds me of Martin Fowler’s great article stating “Different people reading about MVC in different places take different ideas from it and describe these as MVC”. Similarly, and IMHO I’d say
Asking me, based on my different background I might say as a/an (don’t take me too serious)
It must be built with SpringBoot because Netflix and other big players use it, and they must be right + all latest books about Cloud Native tell me I have to use SpringBoot.
What’s Cloud Native? For now I have my “monolithic” ABAP stack on-premise, let’s wait for ABAP in the Cloud. Then I’ll learn what it is/means before I can tell you more.
All I need is some web space that allows me to host my static web apps, and there should be some kind of CDN/WebCache available. Everything else ist REST in practice.
It must run on the SAPCP. Well, with NEO in the past, Cloud Foundry now, and maybe in future powered by Docker + Kubernetes.
Oh, I’m glad I have a few coding skills so that I don’t run out of work + I can jump on the cloud train… And if I can’t jump or if the cloudy ice breaks, I still continue UX because the cloud stuff makes my UX skills not less valuable.
I’m not saying the items are true or wrong. We could also add the POV of a linux/unix dude, a Business dude, or sponsor… Ok, to be more serious, to me Cloud Native means (i.e.)
Of course, there is way more to add (plenty of literature.., i.e. check how Pivotal describes Cloud Native).
Maybe it’s easier to say what’s not Cloud Native:
Nope, you’re not. Maybe your application is. However, deploying an application on any given cloud platform doesn’t mean your application is automatically Cloud Native.
My gosh – hopefully you don’t have a Computer Science background.
Sounds like the number 1 in the Hall of Fame of Cloud Washing: Cloud washing (also spelled cloudwashing) is the purposeful and sometimes deceptive attempt by a vendor to rebrand an old product or service by associating the buzzword “cloud” with it. Lots of companies have done and will keep doing this. However, as devs we’re not stupid, and on longterm we will simply avoid such vendors.
Stopping here now, the answer is already too long. And I’d prefer others to add items to “What’s not Cloud Native”, it can get quite funny and sad at the same time.
It turns out that people, mindset, applications, technology, principles, and infrastructure must work hand-in-hand somehow. That matters even for Cloud Native. Hm… Principles, like a manifesto? Probably The 12-Factor App serves as the manifesto. And the SAPCP might serve as the “right space” (which is esssential as we know from Design Thinking). Just in case you wonder: I’m a big fan of the SAPCP.
Nice one, Nabi! I especially like the personas. I'm sure there are more, but as you say, you've deliberately kept your comment relatively short! I made a typo earlier, and wrote "cloud naive" instead of "cloud native". Perhaps that new former phrase can be used to describe exactly what those last three examples are!
I didn't know about the phrase "cloud washing" - thanks for the pointer. Your reference to the 12-Factor App document was great. It's a document I read relatively recently, and despite its appearance, is eminently readable - I'd recommend it to anyone reading this post and comment thread, as it provides a good frame for thinking about a lot of what I think cloud native is about.