Nineteen hours of flying you say? Yes please, especially when that means exchanging the polar vortex and shoveling my driveway for 25C, the beautiful Darling Harbour, and the pleasure of attending Magento Live Australia 2019! What a great chance to catch up with the movers and shakers of the Magento world in the Asia Pacific region.
We invited all MLAU guests to a happy hour the night before the event. Research was necessary in order to find the perfect location! After a picturesque walk around Darling Harbour scouting out locations, we found ourselves at a lovely outdoor location right next to the ICC. Of course, we needed to sample the menu and were intrigued by this location that featured a Campari bar! We had an amazing team building session at Fratelli Fresh assisted by some of the best negronis ever. Great happy hour, if you’re ever in the area!
We returned the day after to welcome our happy hour guests. We finally got to buy Ben Marks a negroni (long story) and he was not a fan :) He politely nursed it until we rescued him with a beer. The Paypal team was amazing and stopped by before their own team building. Always great to see them. Those amazing negronis, beer, wine, and great company made it a success and we ended happy, full and ready for MLAU!
Bright and early the next morning we headed over to the ICC for day one of MLAU19. Let me say it now – the food was great! Truffled eggs in a breakfast burrito and plenty of good, strong coffee – just the thing to fight off jet lag and get things started on the right foot.
We made sure to attend Paypal’s panel on Closing the Mobile Revenue Gap – a huge issue in ecommerce and we’re certainly doing our part to make sure your site loads as fast as hell. As always, Rob Long hosted a stellar panel with experts like Zee Aganovic, James Horne, and Alana Fennessy.
We have to admit that we mostly attended technical talks – go figure, we’re a bunch of geeks! Big standouts were Anton Kril’s talk where he managed to not accidentally deprecate anything (maybe) and Alex Paliarush’s talk on the ever-improving graphQL support in Magento. Of course, PWA was a hot topic – Magento’s PWA studio has just been released, and sites that can move to PWA promise to have many advantages over those who don’t! Blake Morgan and Carolyn Breeze (Braintree) lit up the stage with engaging talks on customer success and the future of payments. Delighted that we had the unique opportunity of chatting with Carolyn later that evening and yes Carolyn we are waiting for your submission to Meet Magento New York 2019! :)
After a long first day, we were ready to party! We headed down the harbor side to the official after-party. What a blast!
Two things really stood out. There was a photo booth that took synchronized pictures from a bunch of cameras and combined them into cool hologram-like printed pictures – rotating the picture changes the angle of the photo you see. The coolest thing by far was the DJ table. It was a lighted table with a bunch of small tiles around the edge, each with a unique QR code. Placing a tile on the table would alter the music being played at that moment – add or remove a bass line, drum line, melody, etc. Moving the tile on the table would change pitch and volume and raising all the central tiles at once would stop all of the music! It was really intriguing to play with different combinations and figure out how it worked!
This particular team seemed to hog the DJ booth :)
Great fun hanging out with everyone there, and of course, the end of the after party is never the end! Next up, the after-after-party at the Pyrmont Bridge Hotel bar (aka PBH) open 24hrs! No more needs to be said!
Next morning we were ready for day two – with a very healthy infusion of strong coffee! Thank you, Magento for professional coffee makers!
One of the highlights on day two was the dev exchange. This was set up as round table discussions, each with a specific topic, and a moderator (usually from Magento) to help spur conversation and answer questions. We attended both the devbox and the Magento Association/event organizing discussions (two subjects near and dear to our hearts). We enjoyed this chance to freely trade ideas with attendees interested in the topic at hand.
We arrived in Australia with some awesome Mojo Stratus branded headphones that we were dying to give away. We encouraged guests to enter the draw and as the event drew to a close it was time to pick a lucky winner. A random draw came up with Andrew Beale as the lucky winner. Luckily he was still at the event. The headphones surely served him well on his trip home. Look out for the MageMojo team at your next event, you may be lucky enough to snag one of these!
Sadly, it was all too soon time for us to take the long, long flight back home to winter! We packed our bags with Timtams and Vegemite and headed to the airport. We had just gotten to love the expression “How ya going?” and who knew Jennifer Garcia is a DJ at heart! We look forward to our next expedition down under – and to Imagine 2019!
We’ve made the difficult decision to shut down our dedicated server plans on March 1, 2019. As you may know, we have not offered dedicated server plans since last year. While we understand the impact this will have on our customers, shutting down these plans will allow us to focus on improving and adding new features to our latest cloud product, Mojo Stratus.
Our mission has always been to deliver a world-class product for Magento stores. That is why we offered our own hand-picked hardware for years. First with plans using cPanel and then our own server management panel, Mojo Host Manager. Cloud architecture has caught up to bespoke server builds and we are proud to say that Mojo Stratus will half your response times compared to our dedicated hardware. Put another way, your performance will AT LEAST double, guaranteed.
The results speak for themselves, below are graphs from live stores we host showing New Relic average response times before and after the switch, denoted by the red line. After moving to Stratus their sites loaded faster and became more stable, while being able to handle more traffic than ever before.
The Mojo Stratus platform is built entirely on the AWS cloud stack and is hosted on Amazon's hardware and instances. It utilizes containers to automatically scale for a given store as needed. This means that you no longer have to worry about Ram or CPU restrictions.
We've also included Autoscaling, CDN, Web Application Firewall and DDoS protection as part of Mojo Stratus. We use a utility pricing model so that you only pay for what you use. Our Mojo Stratus plans start at $98 per month plus monthly sessions and storage.
We know that you will have a lot of questions about Mojo Stratus. We’ve put together a FAQ document with more information. If you still have further questions or concerns, simply reply to this email and we will get back to you as quickly as possible.
If you wish to sign up today and start the migration process, you can do so at https://magemojo.com/.
Flashback to Imagine 2018 in April. As organizers for Meet Magento New York, we were invited to attend an organizers meeting. The meeting was to learn about the new Magento Association taking over the Meet Magento Association. This was the first time we heard about it and were surprised. At Imagine we learned that 4 community members would be leading it. The meeting was, well, not much. There was very little information provided. Our impression was the Magento Association was transferring ownership of Meet Magento Association.
Since Imagine there have been several more meetings. In these meetings the attendee types started to drift. First organizers from other events. Then Magento Masters. Then community celebrities. Then people from outside the Magento community.
We started hearing Magento Association was more than Meet Magento Association. Magento Association was more than events. But what was Magento Association?
The Magento Association idea started before the Adobe acquisition. The idea came from the fear of losing Meet Magento Association. The M eet Magento Association is the association created by Thomas Goletz in Germany. There's a long history of Meet Magento DE, Meet Magento, and the Meet Magento Association. I won't get into the nitty gritty of it. The important thing to know is that the Meet Magento Association was formed to produce the DE event and to spread more Meet Magento events around the world. But Meet Magento Association never owned the trademark for Meet Magento. Since then Meet Magento Association events have been spread around the globe and in this regard it's been very successful in doing so.
As a member of the Meet Magento Association we pay a yearly fee to the association. The money earned from the DE event (which is the only break even Meet Magento Association event and also earns profits) is used to fund the Meet Magento Association's yearly budget. There has been contention in the DE community for several years. The contention is around having an organizer, one who's not earning a living from Magento, organizing a Magento event. There are opposing pov's here. On one side people question the over-commercialization and revenue generation of MMDE. The organizer yearly fees, where that money goes, and what we as organizers receive back. On the other side is an organization who has full time employees devoted to the Organization and producing MMDE.
Over time, for various reasons, the founder of Meet Magento Association became more involved in China. The contention was growing stronger. The Meet Magento trademark was owned by neither Meet Magento Association nor Magento. Magento saw all this as a risk of losing the Meet Magento events - over 25 worldwide. The German laws are complicated, to say the least. It was easier to form a new association and buy the trademark than it was to take ownership of the existing Meet Magento Association. At this point, the Magento Association was very much about protecting the future of the Meet Magento events. But once you create a non-profit association, how do you manage a community with it?
Magento looked at Acquia and the Drupal Association. They learned that looking back, the Drupal Association really wished they had engaged a professional company to help them. Drupal Association spent years self-teaching themselves lessons that could have been avoided. From these conversations Magento found SmithBuckland. They engaged SmithBuckland to start the Magento Association. Hopefully, this would avoid the wasted time and costly mistakes of the Drupal Association.
Enter SmithBuckland. SmithBuckland has been leading these meetings as a discovery to help form the structure of what Magento Association should be. Up until now Magento only knows they wanted to protect losing the Meet Magento events. Through these meetings they start to realize maybe there's more than just the Meet Magento Association. Maybe they can add more events. Maybe there's potential here for more than just events. That's when more and more unusual people were invited to the meetings. Largely to explore and see what community opportunities there which evolve with every meeting.
Three critical mistakes were made here.
First, they tried to keep this quiet. The reason being they didn't exactly know what they wanted or how to do it. They didn't want the community to form pre-conceived notions about what Magento Association was. Instead, the community was left to draw their own conclusions. Most of us do not have good experiences with Magento's business practices. Nor with their involvement in our events. We were left to draw our own conclusions. Conclusions through the lens of previous negative experiences.
Second, the people invited were not described. Yes, Magento put up a form to fill out if you're interested (which I filled out and never was contacted - another employee was). Yes they reached out to Masters and Event Organizers. But many others appeared and it very much looks like you had to be a friend of certain people to get invited. From a Community POV this is bad optics. A lot of the drift was simply miscommunication between the people inviting attendees and people attending not following the rules. Say what the guidelines are for the people you invited and stick to those guidelines. Enforce your attendance policies at meetings. It's important for the appearance to not show cronyism in order to build confidence and trust in the process.
Third was communication, or lack of. This goes back to keeping things quiet. They should have come out and said clearly what the business goals were driving the decision to create the Magento Association. Just say it. Make sure you announce the form to request your involvement by more than just a tweet. The communication strategy with community needs a major upgrade. As it stands now you pretty much need to hang out on twitter all day to know what's going on (please don't kill me Sherrie - I love you).
SmithBuckland isn't going to be here forever. But before they go they need to figure out who's going to pay for this thing. That's right, it's not Magento, it's us. Surprise! At least it was for me. For some reason I thought with all the unicorns being thrown around that events would be supported and possibly even help funded.
Why would I think that?
Last year at MMNY we didn't receive anything from Magento, not even some stickers. But they wanted free tickets. They wanted private meeting rooms. In fact, we weren't even allowed to say we were an official Magento event. I was personally reprimanded for saying this. I was given a long legal clause to say that sounded like it was the end of a pharmaceutical commercial. It basically said we're not an official event, Magento and Meet Magento Association have a cooperation agreement, and Magento supports the Meet Magento Association. But never, ever, say you're an official event.
Talking with fellow organizers there are many issues with Magento and the Meet Magento events. From stalling on dates, to trying to insert speakers into keynotes only 2 weeks in advance. It's really been unpleasant working with them on the events. In fact, Magento has been downright been obstructing us in some instances.
Here we are with the Magento Association and a decision to make. The Meet Magento Association was collecting dues for basically just the right to use a license to "Meet Magento" (which they never owned). Why would we be interested in participating in Magento Association at all? Events like Titans and Unconference and others have been fine on their own. We've been all been fine on our own, arguably better off without Magento / Meet Magento Association. Why would we want to be involved in this new Magento Association, especially if we're going to be the ones likely to fund it by now sending yearly dues to Magento Association...
Because it's a chance for a fresh start. It's a chance to do this Meet Magento Association thing over. Magento's control should at least in theory be limited due to the 503c status. This limits their controlling interests on the board to a single seat voting/non-voting. The actual structure remains in discussion. What I would like to see is X board seats. The community makes nominations. Nominees accept/decline. Then the community votes on the nominees for the final board seats. It would also be a good idea to decide the distribution of board seats and types to the types of stakeholders. For example in the community - developers, small business merchants, technology partners, etc.
What is Magento Association then. It was the saving of Meet Magento Association. From there it's not sure what it wants to be. In SmithBuckland's own words: "It was also challenging to prioritize stakeholders as it is unclear what is the #1 problem the Association needs to solve or opportunity to capture".
When you hear Magento say "you tell us" they are really serious. They do want to figure it out. They need to figure it out. As an Organizer I'm not sure what they can do for us. We're already established. We already know 90% of what we need to know. If anything, a central calendar of event dates organizers could collab on, to ensure a good distribution of events, would be nice. Some say a simple spreadsheet could suffice. But there does need to be an arbiter and some process to ensure fair play and dispute resolution. Does that need an association? Is it worth paying thousands of dollars per year? Is it worth the hassle of dealing with Magento?
No, we're going to need a heck of a lot more than that if we're going to participate only as a Meet Magento organizer, on our own free will.
But hey, at least right now we have the chance to say what that something more should be. Should it provide efforts focused on building Merchant / Small Business owner communities? Should it provide efforts on security research and protection?
We're on board with all these ideas. We love the community and have always supported community efforts, even at our own expense, and my personal expense. And will continue to do so.
You the community member needs to tell Magento. What is the problem you see that needs solved? What opportunities do you see to be captured? How do you think it should be funded?
The launch and improvement of Mojo Stratus has been a bumpy road. Stratus was launched just before Meet Magento New York. Stratus was our major release and plastered on every wall at MMNYC. We wanted to do something innovative and different with Mojo Stratus.
Stratus is different. Rather than continuing down the path of traditional server offerings – i.e. you get a server, things are installed on it, and you have this big monolithic piece of hardware running whatever you need – we decided to use containers. A long time ago we looked at Docker and containers to use when developing our panel Mojo Host Manager. That was several years ago and containers were an unstable parlor trick. Great for production if you were ok with your production site constantly being on fire.
Support for containers is now widespread especially with Google releasing their Kubernetes technology. We decided to use containers to build the services for Mojo Stratus. All the services your average Magento 2 store would need, and our initial release worked despite several issues. We tweaked, and tweaked, and got through the Thanksgiving sales season unscathed. Then in December major systemic issues began to appear with no obvious explanation.
First, we saw database problems. On Mojo Stratus, Amazon Aurora hosts all the databases. Aurora's main strength is scaling out read replicas. If you have ever tried to set up your own MySQL master-slave setups or other DIY clustering, then you know it is not very fun. Aurora makes this easy and we wanted to have read replicas for future scaling. It is still MySQL, though, and subject to the same problems you might expect from high usage and other bugs in MySQL. What we saw were patterns of locks in MySQL which would freeze all transactions on all stores for a few seconds. Then a huge spike in active connections as all the traffic on Stratus backed up into Aurora. Site alarms would go off, the sky would fall, customers noticed, cats and dogs living together, mass hysteria. We needed deeper insight into Aurora and fast.
Getting insight into Aurora was not easy. We needed something pre-built. Basic stats from AWS or even getting them yourself from the MySQL engine are not useful. That isn’t a fault in Aurora. For an application specific problem you want to see what queries are happening during a failure event. After some trial and error, we came up Vivid Cortex (https://www.vividcortex.com/) and hooked it into Stratus. Vivid Cortex provides tons of information about what queries are running. Vivid Cortex helped us answer questions like:
What queries are running
How often do certain queries run
What databases run certain queries the most
What queries are the most time consuming
We can’t give Vivid Cortex enough love for watching database performance
After gathering a lot of data, we found a pattern. Stratus would lock up during certain types of queries. They would occur during certain actions on particular stores and lock everything up. On top of this, the Magento 2 crons were going haywire. Magento 2 has a bug (https://github.com/magento/magento2/issues/11002) where the cron_schedule table can inflate to infinity. Crons start running all over each other and destroying your server in the process. Certain extensions can have particularly heavy cron tasks within them. Either due to necessity or inefficiencies in the code. And they all run at once.
With a bug causing locks, crons waging war against everything, and bad queries coming in, we had a recipe for poor performance. Even with the massive resources of Amazon Aurora. We used multiple approaches to bring everything under control. First, we notified customers about problem extensions and site code. Second, we started limiting crons ultimately creating our own extension to manage them. We've also pushed forward support for various services like Elasticsearch. Search in Magento should not be the default through MySQL if possible. We are also working on a MySQL reader extension for Magento 2 to take full advantage of Aurora scaling.
Those solutions helped, but we still had issues on the file system side. The file issues left us baffled. We had no issues going through the busiest days of the season Black Friday and Cyber Monday. From the start we have been using ObjectiveFS. An amazing filesystem that lets us store data on S3 and it gets pulled locally. Files are cached to speed up performance, running anything direct off S3 would be very slow. Especially Magento where thousands of files maybe opened and called on a single request.
ObjectiveFS would use a lot of CPU , spike iowait affecting every customer. That issue started in December and was not a problem in the last few months of 2017. The iowait spikes became more frequent and severe, unrelated to specific traffic, and we had to do something. We shopped around for other file system solutions and came up Weka.io. Weka.io is a high performance file sharing solution that offers low latency and high throughput over the network. With most file systems like Weka, you can't get the low latencies needed for an application like Magento.
Weka promised it all with file system latencies in the microsecond range. Well known share tech like CEPH etc all have times in the millisecond. It used its own kernel driver and relied on i3 instances and NVME storage. Again, when loading 1000 plus files per page load, you need low latency, that’s why the switch to SSDs was so important early on for MageMojo. It looked like a drop in replacement file system and we fired it up and got It working.
The initial results were promising. Weka handled 300k request per second for files over the network without issues, and writes were no problem. You could write from one place and see the file nearly instantly from another source. Many frontend and backend parts of Magento write to a file and display it via an ajax request (product image uploads). Where on other systems an image upload would work, but the thumbnail would not appear since the write was not fast enough.
After more testing, we went ahead and moved everyone off ObjectiveFS to the weka.io filesystem. We had a few issues with its configuration, and worked with their team to get everything set up correctly. For a while life was good. But Weka.io added significant latency to the load times, even with its microsecond response over the network. On average about a full second compared to the original ObjectiveFS system. The load time was a trade-off for what we believed to be stability.
In February we had a critical failure on the Weka.io cluster a few weeks after completing our migration to their filesystem. The system was designed to be redundant so that 2 storage nodes can fail without data loss. In our case 3 nodes failed, putting the data in the ephemeral storage at risk of recovery. A bug in the Weka.io software caused the entire cluster to become unresponsive and we were never given the full explanation from the Weka.io team, unfortunately.
We brought the stores online within 24 hours using an older copy of the data. In the following days we restored files as we could and helped bring back stores using their more recent data. We stabilized again on ObjectiveFS. We got back to business . ObjectiveFS was not as bad as we recalled, having fixed some other issues Aurora related. And not long before the Weka failure, we learned about the Meltdown vulnerability.
This is the real kicker on top of it all. Once Meltdown became public knowledge, we learned that Amazon had secretly patched all their systems in mid-December. Meltdown patches coincide with the random systemic issues. We thought they were ObjectiveFS specific. It was not until we went back to ObjectiveFS that we realized there could be a connection. We also had AWS Enterprise support confirm the patching timeline. They were under embargo not to reveal the vulnerability.
In hindsight, that change severely impacted our file system performance and we know the Meltdown patches can hurt the specific load created by Magento especially stat calls, and Magento makes thousands of them per request. Post Black Friday, multiple issues converged to create a sudden unstable system. We failed to identify it correctly and tried to fix it with different technology. In hindsight, that was a major mistake on our part. A lot of sleepless nights paid on that debt.
With the realization about Meltdown and a new look at ObjectiveFS, we resumed testing and making more tweaks. Performance was better but not the best we hoped for. More and more updates gave us incremental improvements. In the first iteration we used multiple ObjectiveFS mounts. They covered many stores on a given physical node, and those mounts existed on all workers in the Stratus cluster. As a store scaled out, the containers already had the files available. Requests would cache the files a container needed on the respective node over time. But with many stores sharing a mount, the cache sizes became very large relative to a store. With such a large cache, any given request needed to fetch a lot of specific files from a large haystack. Testing confirmed it was a major bottleneck.
For Stratus 2.5, the current generation, we moved to having a single ObjectiveFS file mount per store. Each store has its own file cache local to a node running its containers on disk and in memory. We launched Stratus 2.5 2 weeks ago and it has solved every file system issue we’ve received complaints about, especially update slowness in Magento admin. Site performance is faster than ever, according to our New Relic data every store is 30% faster now. Stores with heavy file operations on load show even more improvement.
We’ve also added a lesser known feature called Stratus Cache. Stratus cache directly adds most of your code base into the container images we use for scaling. Stratus caches bypasses the file system for a majority of the system calls and improves performance while making scaling for large sales a breeze. If you are planning a large promotion or traffic influx, please let us know and we help get that working for you.
To contribute back to the community and improve Stratus, we’ve started making our own Magento 2 modules to address specific concerns we have about Magento 2 performance. Our first release was a complete re-work of the cron system in Magento 2. On Github at https://github.com/magemojo/m2-ce-cron . By default the Magento 2 crons can take a server down in the right conditions and they constantly fight each other and run the same task multiple times. Our module eliminates that problem, because it causes issues with stores and vital cron tasks are missed.
Next we have our split DB extension viewable at https://github.com/magemojo/m2-ce-splitdb . Magento 1 CE allowed merchants to easily use a master-slave database setup with a dedicated reader. Stratus uses Aurora which scales by having seamless multiple readers in a cluster. Since M2 CE does not support this at all out of the box, we had to build our solution. We believe Community should be able to scale just as well as Enterprise.
As we near Magento Imagine, we are working on improving the dev experience on Stratus. We provide free dev instances which are the same CDN and stack used by any production Stratus instance. Going forward, we want to include more tools, tests and utilities to make a developer friendly environment. The primary feature will be Live Preview. At the click of a button, customers can create exact copies of their production store, including the database. Then developers can go in and make changes, commit them, run tests, and push to production. Preview sites will be storable so you can save different versions of the site and refer to them as needed. After the initial release of Live Preview, we will be adding tools to perform Selenium and unit tests.
Stratus is now the premiere platform for Magento hosting. Nothing can scale and run your Magento store better. We've come a long way and we are grateful for our customer's patience. Now it's time to get back to business and stop worrying about your server.
Magento is the best ecommerce platform, and Magento 2 offers even greater benefits including better speed, performance, features, ease of use, and customer experience. If you’re setting up an ecommerce store on Magento for the first time, using Magento 2 right out of the gate is a no brainer, but for those already set up on Magento 1, here are reasons to consider migrating to Magento 2.
Magento 2 is everything Magento 1 was and more. It adds a plethora of new features, while maintaining enough familiarity to ease the transition for long time users of Magento 1. Upgrading is something everyone should do, and with fast high quality hosting such as MageMojo, the benefits stack up.
First, Magento 2 offers significant speed and performance boosts by adopting Varnish and PHP7 technologies. The lower page load times are due to full page cache on both Community and Enterprise versions of Magento 2. Improved performance directly leads to higher revenues. The faster customers can get to your catalog and products, the more likely they are to buy something. Stores upgraded to Magento 2 show higher revenues and conversion rates than slower Magento 1 stores.
PHP 7, is the latest version of the most popular web programming language and is much faster in execution than PHP 5.x. It even outperforms or hits parity with HHVM (Hip Hop Virtual Machine). HHVM also required a lot of extra work to configure for Magento 1 and the built-in Full page cache (FPC) supports Varnish out of the box.
Magento 1 required a 3rd party extension to incorporate Varnish cache which was difficult to use. It also required an experienced (expensive) hand to get custom themes working correctly. But with Varnish cache the time to first byte goes from half a second or more down to only a couple hundred milliseconds. And total page load may be less than a second total.
In Magento 2, a simple click in the backend creates a Varnish configuration file for you customized to your store. Varnish and PHP7 together provide faster load times with lower effort than ever before in Magento. Coupled with Magento specific hosting, such as with MageMojo, and you'll have the best performing ecommerce site available.
This aspect is great for both merchants and developers since the ease of use means you can easily customize and edit things without a developer, and even with a developer the chances of issues cropping up is greatly diminished.
The best part? No extensions are required for payment gateways such as Paypal and Braintree, which are all automatically integrated into Magento 2.
Even more improvements were put into the frontend. The customer experience is the most important part of any store, and Magento 2 adds features that shoppers expect on a modern website. The checkout, cart and registration are all streamlined, faster, and much easier for customers to use, reducing cart abandonment. The cart is now Ajax to reduce loading times (meaning no full page refresh is needed after adding a product). The catalogsearch is also faster and on Magento 2 Enterprise supports Elasticsearch by default and shipping configuration is simpler as well.
The above changes on the frontend extend into the mobile realm, as almost a majority of shoppers today are using mobile devices. The faster search improves conversion rates for mobile users who rely on it in lieu of navigating through an extensive catalog listing.
On the development side, Magento 2 uses HTML 5 and a responsive default theme, to bring everything up to date to modern web standards. The new marketplace and integration of tools like composer also make upgrading and installing new modules more manageable than Magento 1.
Here are some highlights:
Magento 1 will only stay up to date on security patches for another 3 years, so it’s good to start planning the move to Magento 2 at some point, especially given the major performance boosts it offers. It is also more secure using more modern coding paradigms. The development community will be focused on Magento 2, so Magento 1 will not see much attention anymore. You don’t want to get left behind and this is a fantastic chance to make improvements to your site and usability in the process.
The Migration Tool makes moving from Magento 1 to Magento 2 easy and simple. Custom code, themes, and extensions will have to be redone, but this gives merchants a chance improve your code, add better, tested, extensions and upgrade your site’s theme. Customer and product data can also be directly imported with tools from Magento.
Moreover, when upgrading Magento 2 between versions, it makes sure modules are compatible and if they are not, the upgrade stops. Gone are the days of hoping your upgrade works from Magento 1.
Starting the upgrade is a no brainer. All stores will eventually have to switch to the newer platform so it’s a good idea to start planning the move now, especially so you can maximize on the benefits that much sooner. In the competitive world of ecommerce, you don’t want to get left behind. Better yet, upgrading sooner than later will put you ahead of the curve and give your shop a leg up on the competition. To maximize on this you'll want the best hosting available as well, such as MageMojo which is the number one Magento specific hosting service.
Choosing a platform for your online business is a major decision, but for any ecommerce business, large or small, Magento is a great choice. Roughly a quarter of all ecommerce sites worldwide use Magento as it is agile, flexible, and full featured.
From small to big companies, there are millions of businesses on the Magento platform. Some of the biggest brands including Samsung, The North Face, Ford, Fox Connect, Lenovo, Olympus, Men’s Health, Vizio, Nestle Nespresso and Nike use Magento and so do millions of small and midsized ecommerce companies around the globe. Coupled with powerful hosting like Mage Mojo, the potential of Magento is limitless.
The community marketplace allows you to download extensions to customize your store. Open source means anyone can add to or extend Magento to their needs. And the continued use of open source licensing in Magento 2 shows Magento’s own commitment to the community alongside their Enterprise offerings.
As an open source project, extensions are widely available, both paid and free, for Magento. Just about anything a merchant would need that is not included in Magento can be found with a simple click. Even the software requirements for Magento are all open source (Apache/Nginx, PHP etc) creating an entirely open stack for eCommerce. And many features available to customers, were re-created by community developers, namely the Full Page Cache (FPC). For hosting companies like MageMojo, open source allows their support to recommend free extensions for customers who may not want to spend $100 or more dollars for Full Page Cache capability.
Search is another area with a lot of extensions. Magento 1 and 2 both use MySQL to store search data for the product catalog. Though Enterprise has always had more search options (Apache SOLR and Elasticsearch), commercial modules are available to bring similar solutions to the Community edition. And for many of the features available in extensions, the price is modest compared to the cost of a developer to make a custom module for you.
This means developers can modify the source code to your heart’s content, adding or creating extra features, add-ons, or plug-ins as necessary. This makes Magento an immensely powerful and versatile platform like no other.
As an open source project, Magento is continually reviewed and improved by thousands of developers. It only continues to get better with users seeing constant improvements. These contributions have created an incredibly stable and secure platform for online stores. The Magento Community Edition is also free! The benefit of Magento’s community is immense as security updates are released often as a patch for everyone to secure their stores.
Magento is built to run on established technologies: Apache/Nginx,PHP and MySQL. They are very stable and side effects from the hosting stack are reduced. Plus they are all very scalable to handle. Whether your online store services one town, a whole state, or country, or operates internationally, Magento and its plethora of features can handle it with ease. This ability to grow is why so many businesses choose Magento right from the start.
This scalability extends into the hosting industry. Merchants can choose from a variety of hosting environments, platforms, and other offerings for their store. With the right hosting, such as Mage Mojo, Magento can handle even the Superbowl and other television promotions. It’s no wonder so many Fortune 500 companies choose to run on Magento.
The Magento community is worldwide and ranges from the tiny freelance developers to large web agencies and no matter the size, they all contribute with open source modules and improvements for Magento. Anyone can get help when they need it from helpful communities at the official Magento forums and sites like StackExchange. And with Magento 2 on Github, issues are constantly being reported and discussed. Many are resolved with new contributions for the next release. Hosting sites like MageMojo consistently contribute and work with the community to integrate the latest practices and fresh feedback to make their hosting better.
This means the speed, functionality, and security of your site is forever being improved and new features are constantly being added. This readily available support makes Magento especially appealing for non tech/code savvy business owners.
In fact, as an ecommerce business owner you can meet this community of developers in the flesh at Magento events such as Meet Magento which will be hosted in New York City by Mage Mojo. Not sure what features Magento offers? Still have questions? This is a great place to talk to experts who know everything there is to know about ecommerce solutions and find great inspiration for your own store!
Many merchants also have brick and mortar operations or other external systems particular to their market. Trying to integrate them into other platforms can be a mess, if it is even possible. You may need to track inventory between Magento and your point of sale systems at various franchise locations.
With Magento’s API you can keep your physical and digital locations in sync with ease. The most popular platforms tend to already have modules available for Magento (like Amazon, eBay, and ERP software). For example, a merchant has physical locations along with sales on eBay,Amazon, and their Magento store. Through the Magento API and a few modules, their inventory at their warehouse is synced across all of them automatically and their Magento store doubles as the overall source of truth for all revenues and order processing.
This seamless integration is a major benefit. But even if your shop is purely online, Magento allows for integrations with any third party extension such as payment gateways like Paypal, database applications, shipping, shipment tracking, and has built in integration with Google Analytics and Google Base. Magento is an all in one solution for everything your business needs.
Unlike most other platforms out there, Magento doesn’t limit you to using a single online store. Instead, you have the capability to run multiple stores from the same backend interface, with all of the information for all of your stores available on the same admin panel. Multistores lets any merchant host several domains while conveniently sharing information between them, such as customer data and product catalogs.
Managing a diverse collection of sites has never been easier. With Magento, the hassle of multiple backends and duplicating content throughout your stores is no longer a problem. For example, a site hosting many different brands of the same style of shirt, such as for college sports teams, can re-use content across multi-stores without having to manage dozens of Magento instances. Or many different stores can be used to be region specific, with their own language and products to fit the demographic. From a single admin dashboard, you can control the inventory, billing, and records for all of your stores.
Out of the box Magento packs a ton of features and more than enough to get started for any new merchant. A store can get up and running in no time without the need to install dozens of extra modules. With a low barrier to entry, Magento fosters online competition without excessive risk and merchants have flexibility to try new ideas. We have seen many dropshipping sites get up and running with off the shelf parts - themes and extensions - in less than a week from installation to going live. Magento is user friendly, mobile optimized, allows for search engine optimization and analytics, and is specifically designed for ecommerce.
Coupled with powerful hosting, the possibilities with Magento become limitless. If you’re still unsure, we suggest you attend a Magento event and meet with other ecommerce business owners and developers.
The next Meet Magento event is sponsored by the industry’s leading Magento hosting companies, Mage Mojo in New York City. Innovators and veterans, will be present for you to learn about ecommerce and ways to improve your sales. You can learn about others who have found success with Magento, what features they used, what features are available, glean inspiration, and find out how the community is always integrating the latest tech and improvements. Further details are coming soon, so keep an eye out!
Many changes happen on the servers, from nightly yum updates, to our security scanner updates, to our server configuration updates. In order to improve our change management process we promise to do the following:
EDIT: Please see our status page for more information and for future updates.
On October 26, 2016, at around 2 PM ET we received an alert that a WAN uplink in one of the core routers was down. We determined the optic was failed and needed replaced. A technician was dispatched to replace the dead optic. At 4:05 PM ET, upon inserting the optic in the Secondary router, the Primary router panicked and rebooted into read-only mode. Our tech and network operators immediately restarted the Primary. The reboot took 8 minutes. By 4:15 PM ET the core routers had re-initialized were back online. Our monitoring systems cleared up except for a few servers.
We immediately noticed that our server for magemojo.com was experiencing about 50% packet loss on its internal network. We continued to receive a few customer reports of problems. We scanned the internal network for all customer problems and isolated the packet loss to one /24 VLAN. We thought the problem was related to the abrupt failover of the core routers and decided it was best to try switching back routers to the first Primary. At 6:40 PM ET we initiated the core router failover back to the previous Primary. The failover did not go smoothly and resulted in another reboot which caused another 8-minute network disruption. The core routers returned with the old Secondary as Primary, and the problem remained.
We reviewed the configuration to ensure there were no configuration errors with the new Primary but did not find any. We ran diagnostics on all network hardware and interfaces to identify the problem. We found no problems. We ran diagnostics a second time to check for anything we might have missed. Again, we found no problems. At this point, we started going through the changelog working our way backward to look for any changes that could have caused the problem. We found a change from September that looked possibly related to the packet loss. We reverted the change, and the packet loss stopped at 9:10 PM ET. The core continues to remain stable with the new Primary.
Our core network uses 2 x Cisco 6500E Series Switches each with its own Supervisor 2T XL. Both Sup2T's are combined using Cisco's Virtual Switching Solution (VSS) to create a single virtual switch in HA. Each rack has 2 x Cisco 3750X switches stacked for HA using StackWise with 10G fiber uplinks to the core 6500's. Servers then have 2x1G uplinks in HA, 1 to each 3750X. Our network is fully HA all the way through and at no point should a single networking device cause an outage. We have thoroughly tested our network HA and confirmed all failover scenarios worked perfectly. Why inserting an optic into a 6500E blade would cause the other switch, the Primary, to reboot is completely unexpected and unknown at this moment. Why a single switch rebooting would cause both to go down is unknown. Why the previous Primary failed to resume its role is also unknown. We have Cisco support researching these events with us.
The packet loss problem was challenging to figure out. First, it wasn't clear what the common denominator was among the servers with packet loss. Packet loss happened on servers across all racks and all physical hardware. We thought for sure the problem was related to the abrupt switchover of the core. We focused our search isolating the packet loss and narrowed it down to one particular vlan. Why one vlan would have packet loss, but not be completely down, was a big mystery. We thoroughly ran diagnostics and combed through every bit of hardware, routing tables, arp tables, etc.. We isolated the exact location the problem was happening but why remained an unknown. Finally, we concluded the problem was not caused by the network disturbance earlier. That's when we focused on the change log.
The change was related to an "ip redirects" statement in the config and how we use route-maps to keep internal traffic routing internally and external traffic routing through the F5 Viprion cluster. During tuning of the Sup2T CPU performance, this line changed for one particular vlan. At the time it created no problems and packets routed correctly. However, after the core failover, the interfaces changed and subsequently the F5 Viprion cluster could not consistently route all packets coming from that internal vlan back to the internal network interface from which they originated.
Honestly, we did few things wrong. First, we should not have made any changes to the core network during the afternoon unless those changes were 100% mission critical. Second, we jumped right into fixing the problem and replying to customers but never publicly acknowledged the problem started. Third, our support desk overloaded with calls and tickets. We tried very hard to respond to everyone, but it's just not possible to speak to 100's of customers on the phone at once. We were not able to communicate with everyone.
We're re-evaluating our prioritization of events to reclassify mission critical repairs. All work, even if we think there is zero chance of a problem, should be done at night and scheduled in advance. Customers will be notified, again, even if we don't expect any disruption of services.
We also know that we need to post on Twitter, our status page, and enable a pre-recorded voice message that says "We are aware that we are currently experiencing a problem and we are working on the issue." as soon as we first identify a problem. We're working on setting up a new status page where we can post event updates. We're also working with our engineers to guide them on how to provide better status updates to us internally so that we can relay information to customers. Unfortunately, during troubleshooting, there is no ETA and any given ETA will be wildly inaccurate. But we understand at the very least an update of "no new updates at this time" is better than no update at all.
Finally, we're working with Cisco engineers to find the cause of the reboot, upgrade IOS, and replace any hardware that might have caused the problem.
Thank you for being a customer here at Mage Mojo. We want you to know that we work incredibly hard every day to provide you with the highest level support, best performance, and lowest prices. Our entire team dedicates themselves to making your experience with Magento a good one. When something like this happens, we hope you'll understand how hard we work, and how much we care about you. Everything we do is for you the customer and we appreciate your business. Trust in us to learn from this experience and know that we'll grow stronger providing an even better service for you in the future. Thank you again for being a customer.
We are scheduling a network maintenance window on Thursday November 10th 2016 from 12AM ET to 1AM ET. During this window will replace a faulty line card in our core network and upgrade our version of the router software. This line card is partially responsible for the outage that occurred on Oct 26th. The other problems were two bugs identified in ios CSCts44718 and CSCui91801.
For this replacement, we are hoping to be able to replace the card with only minor network interruption of a few seconds, but due to the state of the card, it may require a reboot of the network routers which would require approximately 15 minutes of downtime. After replacing the line card, we are going to perform an in-service software upgrade (ISSU) which should not cause any downtime. We do not anticipate a network disruption during the full window, but we are scheduling an hour window in case we run into any unanticipated problems.