Evernote: “Until now, Evernote has owned, configured, and maintained its own servers and networks. This approach gave us the ability to build the service we wanted the way we wanted to build it. But it is also limitingâ€”expensive to maintain, slow to upgrade, and difficult to scale. And while the infrastructure we have now is perfectly suited to support Evernote as it runs today, it lacks the speed and flexibility we need for tomorrow.”
It’s interesting to see Evernote make this move. It almost feels like they’re hoping Google will purchase them. We’ve all heard that Evernote is in trouble and only time will tell if there’s anything to that rumor.
John Gruber: “What went wrong was very simple. We never made enough money. Why we didnâ€™t make enough money, what we should have done differently to make more money â€” those are complex questions (which Iâ€™ll tackle below). But what actually sunk Vesper was not complicated. Even as a relatively popular app at a relatively high price (for iOS), revenue was never high enough. Brent took a job at the excellent Omni Group in September 2014, and from that point onward the writing was on the wall. We could have, and probably should have, shut Vesper down a year ago. But we loved it too much. Or at least I did.”
Brent Simmons: “This is the last app on the App Store where I wrote all (or almost all) of the code. Odds are excellent that there will never be another app written largely by me on any app store.”
It’s hard to make decisions like this. Vesper was the result of a lot of hard work by a small group of dedicated people. Vesper will be missed, by them the most.
The most fascinating part of this entire post mortem from John and Brent is the belief that creating a Mac App first may have lead to success. Obviously these guys know their Mac brethren better than I, but I always thought a subscription model was a better option for them, and I wrote about it in 2015.
I think the idea of a sustainable business is the right way to look at this, but pricing an app at $9.99 isnâ€™t the proper solution. The proper solution is to charge for their â€œfast, reliable, unlimited sync.â€ Thatâ€™s the value, the app is just a way to get to your data.
Obviously there are a few really great companies out there making a go of it but the market has changed so dramatically from the time Brent started Ranchero. At the time the Mac wasn’t nearly as popular as it is today and the App Store model didn’t exist. Sure, you still needed a great product and had to work hard to get the word out, but people still understood the value of software. Today iOS and Mac Apps have been reduced to commodities and commodity pricing. Most people expect free and get it from companies that make their money other ways, including services, which is why I think the service is the most valuable component. Does it mean you should only do services and not native clients, no. The client side provides the great experience and the service opens the door to the magic of data flowing from one point to another. Without both sides you can still have a great experience but it may not be as great as it could be.
Thanks John, Brent, and Dave for giving us Vesper.
Microsoft Azure Blog: “We created a Parse Server implementation that uses fully-managed Azure Services and released it on the Azure Marketplace. With this template, Parse developers will be able to easily spin up a Parse Server v2.1.4 with a suite of pre-integrated Azure services.”
The closure of Parse has actually allowed the platform to blossom. The community has been amazing, the Parse team has been amazing, and now we’re seeing other platform vendors pick up where Facebook left off.
I think this would be my first choice for continued Parse deployments. I haven’t used Azure myself but I trust the opinions of some folks that have. I’ve heard the management console is much nicer than AWS, not to pick on AWS because I’ve actually used and like AWS, but the Azure team is continuing to build out incredible infrastructure that can run any operating system and service you’d like to host there.
This year at Build Microsoft seems to have really doubled down on services and Azure, along with announcing free Xamarin tools for Visual Studio, a plugin to Visual Studio that allows for building on Linux, and a native implementation of Bash on Windows. Those are just a few of my favorite announcements, I’m sure there are many others I missed.
We live in interesting times and Microsoft definitely isn’t sitting still. They are becoming the place for Services and Mobile Apps.
Mac360: “In recent years Apple has used Microsoftâ€™s Azure cloud infrastructure and Amazonsâ€™s Web Services, as well as itâ€™s own data centers, as a mashup melange which together makes up iCloud and other cloud services. Thatâ€™s right. Appleâ€™s iCloud and cloud services come from Microsoft and Amazon. And soon Googleâ€™s Cloud.”
I find this fascinating. You’d think Apple would have their own services, hosted on their own hardware, in their own facilities. Read the article and, like me, you’ll discover they just didn’t have the bandwidth to standup a facility the size of Azure or AWS or Google just to serve their customers. Wow, that is amazing growth.
I would really love to see a report outlining all the technologies Apple uses to serve iCloud customers. Everything from service providers to hardware to software stacks and how massive each of those really is. It has to be mind boggling. Makes me wonder if any one person at Apple knows the answer for all the services, top to bottom?
Wired: “But Goâ€™s â€œmemory footprintâ€â€”the amount of computer memory it demands while running Magic Pocketâ€”was too high for the massive storage systems the company was trying to build. Dropbox needed a language that would take up less space in memory, because so much memory would be filled with all those files streaming onto the machine. So, in the middle of this two-and-half-year project, they switched to Rust on the Diskotech machines. And thatâ€™s what Dropbox is now pushing into its data centers.”
Read the entire story if you have a couple minutes, it’s a nice read. I love reading about custom infrastructure build-outs because they’re so rare and specialized. The bit I found super interesting and scary at the same time was the transition from Go to Rust in what looks like a move after proving it worked as expected. It seems like that is such a risky thing to do, but still entirely fascinating.
It’s also amazing how fast things change on the backend vs the native client side of things. I’ve been coding professionally for well over 20-years and in that time I’ve developed applications in C, C++, C#/.Net, Objective-C, and Swift. That’s it. In the past few years it feels like new languages are developed every day.
At Agrian we develop native clients on iOS in a mix of Objective-C and Swift, with all new code being written in Swift, and we have a combination of C#/.Net and Ruby on Rails for our backend services, with some new stuff being built in Scala. I know those aren’t what the cool kids use, except maybe for Scala, but they’ve proven extremely reliable. Our deployments are stable and easy to publish and the services continue to churn and chew on new data without issue. Of course we don’t have scale like Dropbox or a lot of the other big players, but it’s been very reliable depending on Ruby on Rails for our particular needs.
Adobe Creative Cloud Blog: “Over the years, weâ€™ve learned a lot about what you need and have created tools so you can deliver your best design work. As technology has changed, so has the way that you approach your work. Instead of one screen, you now have to think about multiple screens and how the experiences youâ€™re creating relate to each other.”
This looks like an awesome new entry in the Adobe Creative Cloud Suite. I’m sure many designers would like the ability to create a design, hook it up, and demonstrate it in the correct context of the device.
The video below focuses on a mobile application and how a designer may use Comet to quickly try new transitions between views. It looks like a real winner.
Adobe has a great track record of providing cross platform tools. I wonder if Comet will run on Windows and Mac, or have they made a clean break and focused on one platform?
Etsy News Blog: “Today, Etsy launches a solution for our sellers based in the US to accept credit and debit card payments in person and help manage their multi-channel sales more efficiently.”
My dear wife has a store on Etsy for her little crafting business, Ragamuffin Design. She’s been using Square at craft shows and has been evaluating other store solutions that offer tighter integration with her domain, but the introduction of this card reader connected to Etsy’s service to manage inventory and collect payments is hard to ignore.
At a recent craft show Kim used this new reader and the Etsy application to great effect. I’d say it’s a winner and may be a good option for others running small businesses. I didn’t get a chance to use the app or accept payments with it, but I would change one small thing in the iOS Application. I would allow it to rotate upside down. On an iPhone 5 the app is upside down if you want the card reader at the top.
I do find it interesting Square hasn’t created an SDK for others to hook into. With the advent of Apple Pay I would hope they’d open up a bit. Access to credit and debit cards is still necessary for little businesses like my wife’s crafting business. Collecting cash isn’t the only thing she needs to do. She also needs to manage inventory on her site.
Big Cartel is a small, tight-knit, company that provides a white-label storefront for indie artists, crafters, and whatever else you’d think to sale online. They have a small (500,000) set of very loyal customers that manage their day-to-day online sales using the platform. They also have a really nice iOS client application that is missing one small thing. The ability to support swiping credit cards on the go. They do provide a way to collect money by typing in credit card numbers, it works, but is less convenient and error prone. They could really benefit from a Square SDK. They need this kind of integration because, like Etsy, they can manage your product inventory as the transaction is completed. Doing that after the fact is a real pain, I know, I’ve seen my wife do that after shows, prior to using the Etsy card reader.
I’m also a bit surprised someone like Stripe hasn’t created a white label reader with an SDK. Couple that with an open platform from someone like Big Cartel and you suddenly open possibilities for third party developers to create all kinds of interesting solutions.
Medium: “9am: Kevin and I panic as our tiny server crumbles under the weight of our first-day traffic.”
In this day of large scale systems it’s hard to believe Instagram launched with a single server, which promptly melted down under the strain.
On Wednesday, October 6, 2010, Instagram launched its mobile photo sharing service for iPhone. In six hours, the back-end operation, which was running off a single machine in Los Angeles, was completely overwhelmed.
That’s from a 2011 Mashable article. I’d love to know how many boxes Instagram runs off of today. This stuff fascinates me.
The Loop: “Do something like Medium or Svbtle that doesnâ€™t have the complicated backend and code. Thatâ€™s what I want.”
I probably harpon thistoo much. I’ve been browsing around for a simplified weblogging tool, but WordPress is just too darned good to give up. I would, however, love to see a version of WordPress that would allow me to publish everything as static HTML. Decouple the composition from publishing, make them separate services. I compose a post, save it, when I click “Publish” the site is regenerated and pushed to my domain. That’s it. I would also be nice to have a quick and dirty post editor that doesn’t include all of the administrative functionality, think QuickPress in a standalone web app, or maybe a desktop app (that would be really nice.)
Make sure you read the linked article, The future of WordPress: “By incorporating a RESTful application programming interface (API), current WordPress apps could be supported, as well as mobile apps that use WordPress as a backend.”
This is how all sites, web app type sites, should be constructed. It’s all about services. Create a service, use the same service from the web app and mobile and anything else connected to the internet. Yes, yes, yes!
HHVM Blog: “As of WordPress 3.9, and HHVM 2.0 the following changes arenâ€™t necessary as WP have updated their codebase to play nice with HHVM, and HHVM has updated itself to support more PHP stuff.”
I know it’s not in style to learn PHP, but it suits the old man C developer in me. I found myself reading about HHVM and Hack which lead me to think WordPress on HHVM might be kind of cool. One little Google search and what do you know, someone else had the same thought, and made it work. Not only did they make it work, but it looks like the HHVM and WordPress folks worked together to make it happen. Even better.
Maybe one of these days I’ll have time to get an HHVM based WordPress installation up an running.