Early adopters delighted as Microsoft pulls plug on Mobile Backend as a Service. Haha, only joking – they're fuming Microsoft is shutting down its Mobile Backend as a Service (MBaaS), part of App Center, to the dismay of developers using it. App Center is a service for building and testing applications for iOS, Android, Windows and macOS. It has continuous integration, where code changes committed to a repository in GitHub, Bitbucket or …
MS is continually shafting developers - all the time. All those mobile OS attempts where they dumped devs before moving onto another attempt (5 or more times!), continually moving goalposts with app stores, trying to phase out win32 in favour of store apps, then reversing decision. I just don't understand how devs trust MS one tiny bit anymore. All MS are interested in these days is Azure and cloud - everything else is superficial. If they can lock you into their cloud services, it's job done.
There is no rational reason for that to be the case.
It seems we increasingly live in a throw-away society that clutches only the new and shiny for a short time before discarding it.
The thread on Dephi's 25th birthday on this site should testify to the fact that applications written that long ago can still be productively supported with minor changes.
They did the same with Windows phone. By which I mean burned their early adoptors.
I was sent one by O2 to try out. What it did well, I liked, but it was very early days of Phone 7 and there were not so much rough edges, as just completely missing capabiltities - it felt very much like a pre-v1 iPhone.
Then MS decided to start again and threw all of their early adoptors under a bus - you simply couldn't upgrade an existing handset. And it always struck me that they could have fairly easily forked their newer phone OS to only include bits the existing hardware would've supported, but no.
I think that, more than anything else, was the number one reason MS's foray into mobiles died on its arse. Users spent their hard earned currency to buy into a new ecosystem only to be completely abandoned...
But at lease MS appear to have learned from that and...oh, hang on.
And then they did it again with the move from Windows Phone 8 to Windows Phone 10. Microsoft have more than demonstrated that they can't be trusted with new products time and time again. Unless something has been core business for them for a good decade I am seriously reluctant to buy into it now.
I wouldn't buy anything that was their traditional core business nor new business (I have worked as a Windows admin for over 20 years). All that is cared about in Microsoft is how can they get people to use Azure services, so they get subscription income. Everything else is to be slowly burned to achieve that goal.
"It has continuous integration, where code changes committed to a repository in GitHub, Bitbucket or Azure automatically trigger a build process,..."
That doesn't sound like a very stable way of building anything; bringing in random versions of external dependencies each time you build? Surely, a more sensible approach, and the one that sensible people follow, is to have fixed, known versions of external dependencies. So that when you DO update them and stuff breaks, you have a slightly better idea of why. Not to mention having a handle of what versions you shipped with your product to customers.
Oh hang on though! I get it - "sensible" isn't cool is it? Duh! Silly me.
I'm very well aware of that. The vast majority of what I make doesn't go to customer. But it still needs to work and including random versions of external libraries that might change at any time is, quite frankly, a bonkers way to proceed.
How do you version control it? I can check-in version 42 of my code and declare that it' works. But if the version I tested was built against some random versions of some libraries it uses, then version 42 is meaningless and (short of trolling through the build logs to dig out the actual versions used) impossible to reproduce
I'm very well aware of that. The vast majority of what I make doesn't go to customer. But it still needs to work and including random versions of external libraries that might change at any time is, quite frankly, a bonkers way to proceed.
Well don't allow your build tools to use un-versioned upstream dependancies. All of the build pipelines I've worked with have the facility to define package versions to be used in a build and lock on those versions until you decide to upgrade. If you're not doing that or have dependencies that are only defined as version-latest then it's not the fault of your build pipeline...
I don't think you understand what continuous integration is - it's about doing things off the back of changes from your source code - generally on branches in a VCS - not your dependencies'.
If you have your project set up properly using things like package lock files, then the build process run under your CI will bring in the same versions of dependencies every time, until a developer commits a change that specifies different ones. And if you can't manage doing that locally on a developers' machine then you really shouldn't even be using a CI tool.
Except when done properly, continuous integration also runs the tests and won't deploy on test failure. Even better systems won't allow the commit without those tests or fail the push on failed tests.
Putting those things in the past is bad devs or bad management blaming the methodology when it's really on them. See also: Agile.
And the continuous validation of the tests, extending, validating, adding to them as necessary due to upstream, and local changes? This is the bit that's often missed, and combined with what is now considered normal, but appalling error handling - just throw an exception and don't care, things go awry very quickly on anything non-trivial. And by non-trivial I tend to include anything with user interactivitity beyond a "Hello World" popup with a close button - and I've seen developers make a mess of this one. Timing or resource or alternative route bugs are somewhat more difficult to automatically detect and codify in test libraries.
"It has continuous integration, where code changes committed to a repository in GitHub, Bitbucket or Azure automatically trigger a build process..."
That doesn't sound like a very stable way of building anything; bringing in random versions of external dependencies each time you build?
It'll only do that if you want it to. Say hello to lockfiles.
This post has been deleted by its author
Almost all businesses have some uncontrolled existential risks.
Supplier failure is often the greatest risk - if you suddenly cannot buy the widgets/services you use at the budgeted price, searching for an alternative is very expensive. It takes up a lot of work hours that would otherwise have been spent on your actual products, and because it's urgent then it costs more to buy too.
It's even worse when all the alternatives are incompatible, as you now have to spend further work hours adapting your product, instead of improving it.
Think what happens when an IC goes unexpectedly obsolete. The company suddenly has to buy a lot of them at vastly inflated prices to cover existing orders, while also developing a new version that uses alternative ICs as fast as possible.
Even if they can afford the redevelopment time, if the result is zero shipments/service shutdown for a month (because of a lack of widgets/services), existing customers may invoke penalties (SLAs etc).
So yes, this may well sink a few small businesses that are otherwise healthy - if their cash reserves or available borrowing aren't quite large enough to pay for the redevelopment time and contract penalties, they'll run out of money and close.
Xamarin.Forms isn't really a Microsoft product. It was a Xamarin product they bought, rebranded to Visual Studio for Mac and then left it to rot, like most of their acquisitions.
I hardly see anyone using it now for crossplatform iOS/Android devs. When it was invented it made some sense to develop in .net because Windows Phone was still a thing so you got that platform basically for free, and iOS/Android with a bit of extra work.
Now it's more common to see stuff like react mobile (from facebook) and flutter (from google) which basically do the same with webapps. Develop a webapp and get basically native-like mobile apps easily. But not really native, the experience is still not as good as a real native app IMO, especially with flutter which 'redraws' most UI elements to look like native.
Who knew that trusting your entire business to run on computers you don't own and have no control over whatsoever could be any sort of risk? Who'd have thought that the cloud 'service' provider could let you down after taking your money? I mean, who know that Microsoft has decades worth of experience in shafting the customers? Colour me totally suprised.
Expect many, many, many more of these stories.
Anytime you base your business model on a) someone else's b) some cloud service c) not-your-computer you're at the whim of others. It's a dangerous place to be.
Please don't cry when they pull the plug because their experiment is not going as they thought it would.
When will we learn.
"Microsoft has always been focused on enabling developers to be more productive, to achieve their ambitions, and subsequently make the world better for it."
Bull hockey! Microsoft is in BUSINESS to make MONEY! Nothing else. There clearly isn't enough cash being generated by the product to keep it breathing. There's a reason we dubbed Microsoft back in the 80's Moneysoft.
I lost the original URL for these, but enjoy!
10. Specifications are for the weak and timid!
9. You question the worthiness of my code? I should kill you where you stand!
8. Indentation?! - I will show you how to indent when I indent your skull!
7. What is this talk of 'release'? Klingons do not make software 'releases'. Our
software 'escapes' leaving a bloody trail of designers and quality assurance
people in its wake.
6. Klingon function calls do not have 'parameters' - they have 'arguments' - and
they ALWAYS WIN THEM.
5. Debugging? Klingons do not debug. Our software does not coddle the weak.
4. A TRUE Klingon Warrior does not comment on his code!
3. Klingon software does NOT have BUGS. It has FEATURES, and those features are
too sophisticated for a Romulan pig like you to understand.
2. You cannot truly appreciate Dilbert unless you've read it in the original
Klingon.
1. Our users will know fear and cower before our software! Ship it! Ship it and
let them flee like the dogs they are!
Trust & continuity are not words one uses to describe their products or actions. Dealing with them is like crossing a mine field in a hail storm blind folded. Something going wrong is almost guaranteed. And, most likely, terribly wrong.
Does anyone else suspect that Microsoft created & programmed Donald Trump? His updates, like his actions, do go side-ways a lot. Just say'n.
God bless.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
