Tag: open source

  • WhiteSource Raises $35M to Mainstream Open Source Security Management

    Accelerated revenue growth, tripling YoY, underscores rapid market adoption of automated Open Source management

    TEL AVIV, Israel, Oct. 17, 2018 /PRNewswire/ — WhiteSource, the leader in continuous open source security management, announced a $35 million funding round led by Susquehanna Growth Equity, with participation by existing investors 83North and M12 – Microsoft Ventures. This $35 million Series-C adds to the $11 million raised by WhiteSource in previous financing rounds.

    Founded in 2011, WhiteSource was created with the mission to help businesses harness the power of open source without compromising on security or slowing development. With the latest funding, WhiteSource plans to double down on serving the enterprise market where leading customers such as Microsoft, IBM, Comcast and KPMG already leverage the WhiteSource platform.

    Open source has become the main building block in modern applications, and it is almost impossible to develop software at today’s pace without it.  However, as the open source community grows, and the number of reported vulnerabilities keeps climbing, manually verifying the security and compliance of open source components can no longer provide the necessary control over the security of these components.

    “We are now at a stage where the question is not whether or not to use open source components, but how to put in place the solutions and policies to manage them well,” said Rami Sass, Co-Founder and CEO of WhiteSource. “Microsoft’s acquisition of GitHub for $7.5B showcases that companies have accepted open source as crucial to the software development process, but incidents such as the Equifax data breach underscore the necessity for all companies to protect their products from attacks that would exploit the open source components they are using.”

    This reality is the fuel behind the incredible growth of the Software Composition Analysis (SCA) market which automates open source components management. This market quickly transitioned from early adopters to the early majority over the last 18 months and is now becoming mainstream. Serving more than 500 customers today, WhiteSource has established itself as the leader in the SCA space with the first continuous, automated open source management platform.

    WhiteSource continues to gain attention for its ability to think beyond the abstract concepts of security and compliance and has delivered capabilities that answer the business needs of development and security teams alike, as it has proven with its latest revolutionary offering, Effective Usage Analysis, which reduces open source vulnerabilities alerts by 70%.

    “WhiteSource has established the standard for open source security solutions with its strong leadership and breakthrough innovation,” said Martin Angert, Director at Susquehanna Growth Equity. “We are excited to join WhiteSource on their journey to help businesses develop better software, faster.”

    With offices in New York, Boston, and Tel Aviv, WhiteSource is planning to further expand its reach with the opening of sales, marketing and customer support operations in London and San Francisco as well as additional locations for global expansion.

    About WhiteSource

    WhiteSource is the pioneer of open source security management. Founded in 2011, its vision is to empower businesses to develop better software by harnessing the power of open source. WhiteSource is used by more than 500 customers worldwide, from all verticals, and sizes, including 23% of Fortune 100 companies, as well as industry leaders such as Microsoft, IBM, Comcast and many more. The company has been recognized by Forrester as the best current offering in its Software Composition Analysis (SCA) Wave™ report. For more information, please visit www.WhiteSourceSoftware.com

  • Implementing ChatOps Using Open Source Tooling

    Implementing ChatOps Using Open Source Tooling

    ChatOps is an exciting proposition for organizational Ops communication. Throwing development and operational tooling into the chat conversation can ease the development pipeline, increase transparency and increase security by streamlining bug detection and remediation efforts.

    At the heart of ChatOps are bots, scripts and chat clients; many are pre-built and open source. In this article, we’ll review a completely open source method for building out your ChatOps setup. We’ll cover integrating with Hubot, using CoffeeScript commands, and how building custom scripts can ignite ChatOps in your own environment.

    Why Open Source for ChatOps?

    Many arguments have been given as to the benefits of open source. Building upon open source inherently evades vendor lock-in, enabling more security and service longevity. Furthermore, to avoid reinventing the wheel, forking existing open source ChatOps projects naturally will be more efficient than purely greenfield initiatives.

    Open Source Chatbots

    There are many Chatbots available for use; each with unique capabilities, varying types of integrations out of the -box, and different ways to extend functionality with custom scripts. Take Lita, for example, an open source chatbot built with Ruby. It works with IRC, HipChat and Campfire. Many other open source chatbot options exist, such as Errbot, Jarvis and Lazlo.

    Example: Hubot

    By far the most adopted open source ChatOps companion is Hubot. Designed and open sourced by Github, Hubot takes market share in the ChatOps discussion. Described as “a customizable, life betterment robot,” Hubot is written in Node.js and takes commands with CoffeeScript.

    Using Hubot, developers can initiate commands with Hubot scripts to perform actions such as post images, translate languages and integrate with maps, but also initiate vital commands to your favorite DevOps cloud tools. A full catalog of scripts can be found here, and it’s quite easy to craft your own CoffeeScript commands as well.

    Example Hubot Scripts

    The community scripts that support Hubot are similarly open source, meaning that you can repackage these implementations to suit your own needs. Let’s take a look through the catalog of Github-supported Hubot scripts to see what sort of pre-constructed extensions we can seamlessly add to a Hubot environment.

    With Hubot, you can ping your major cloud development platforms, such as Heroku. Some example commands for returning status of issues on Heroku include:


    hubot heroku status - Returns the current Heroku status for app operations and tools hubot heroku status issues <limit> - Returns a list of recent <limit> issues (default limit is 5) hubot heroku status issue <id> - Returns a single issue by ID number

    Or perhaps you want to conveniently check PagerDuty from your chat client to see who is on call within your incident response team, or to gather details on current incidents. Hubout has a script for that. Using pagerduty.coffee, some example requests might be:


    hubot who's on call - return the username of who's on call hubot pager me trigger <msg> - create a new incident with <msg> hubot pager me incidents - return the current incidents hubot pager me notes <incident> - show notes for incident #<incident> hubot pager me problems - return all open incidents

    Another example could be direct interaction with the Twilio API for sending SMS. Using sms.coffee you can initiate a command with the following syntax:


    hubot sms <to> <message> - Sends <message> to the number <to>

    Configuring sms.coffee is easy, all you need to insert are:


    HUBOT_SMS_SID HUBOT_SMS_TOKEN HUBOT_SMS_FROM

    Of course, there is no shortage of Gifs, cat memes, and other scripts to add some humor to your workday, such as mustache insertion using image detection.

    Generating Your Own Hubot Scripts

    Aside from using third party scripts, you can always craft your own. To be an executable Hubot script, your code must be in .coffee or .js, and it must be in the correct directory (src/scripts and scripts by default). It must also export a function, as in the following:


    module.exports = (robot) -> # your code here

    Essentially, Hubot listens to all chat communication; it will hear commands and respond accordingly. To configure what it must hear in regards to your script, you must specify what to listen for, and what to respond with. For example:


    module.exports = (robot) -> robot.hear /badger/i, (res) -> # your code here robot.respond /open the pod bay doors/i, (res) -> # your code here

    For further details, see the documentation on Scripting here.

    Getting The Most of Chatbots

    Once integrated into a chat platform such as Slack, your chatbot configuration can truly thrive. Given the wide breadth of community generated and Github-maintained scripts, DevOps teams have near unlimited potential for uniting their tooling into a single, human-readable CLI. Another benefit of choosing open source tools for such projects is that you can detach your bot and integrate with whatever chat client you prefer.

    ChatOps can add fun and efficiency to the remote workspace. We’ve covered high-level methods for adopting this into your team’s space, and hopefully, a helpful foundation into the power of open source for streamlining the power of ChatOps.

    — Bill Doerrfeld

  • Pivotal Software Extends Development Platform Reach

    Pivotal Software Extends Development Platform Reach

    Pivotal Software announced an expansion of its implementation of the Cloud Foundry platform-as-a-service (PaaS) environment in addition to extending its support for Kubernetes to the Amazon Web Services (AWS) public cloud.

    At its SpringOne Platform 2018 conference, Pivotal revealed that Pivotal Cloud Foundry (PCF) can now extend a single instance of its distribution of the open source PaaS across multiple data centers. In addition, Pivotal is making it possible to automatically update the operating systems on which its PaaS is hosted, and added a more extensible user interface to its PCF Healthwatch monitoring tool.

    What’s more, Pivotal announced that Pivotal Container Service (PKS), its implementation of Kubernetes, now can be deployed on EC2 instances of the Amazon Web Services (AWS) public cloud. PKS is currently based on version 1.11 of Kubernetes that has been packaged with a software-defined runtime for spinning up clusters known as Kubo, developed under the auspices of the Cloud Computing Foundation (CFF), which also oversees Cloud Foundry. PKS was developed in collaboration with VMware, which is a sister company of Pivotal operating under the same Dell Technologies umbrella, and the latest version adds the ability to configure a namespace or cluster to emit logs to a specific destination, such as VMware vRealize Log Insight, without operator intervention.

    Richard Seroter, senior director of product for Pivotal, said Pivotal and VMware are collaborating to make Kubernetes clusters more accessible to enterprise IT organizations that typically don’t have engineers available to manage IT operations. By combining automation frameworks from VMware and Pivotal, the expectation is that PKS will gain more traction as IT organizations evaluate which flavor of Kubernetes to deploy in a production environment, he added. A recent research report published by the Cloud Native Computing Foundation (CNCF) would suggest that strategy is starting to gain traction.

    Pivotal apparently is pursuing a dual application development strategy. The first is based on a PCF framework that is highly prescriptive in terms of how applications should be built and deployed. The second is a more flexible container-as-a-service (CaaS) platform based on Kubernetes.

    In general, organizations that have invested in Cloud Foundry to deploy a PaaS are not likely abandon it in favor of a container platform overnight. But Pivotal and the CFF are under some pressure to be more aggressive in unifying Cloud Foundry and Kubernetes: There already are several instances of Cloud Foundry that run on top of Kubernetes, and Pivotal Software revealed earlier this month that it missed Wall Street’s expectations for billing revenue in its most recent quarter by 25 percent.

    It may take a while for the relationship between Cloud Foundry and Kubernetes to become more firmly established in the minds of IT professionals. But there are certainly no shortage of options when it comes to developing modern applications—there will be more than a few organizations employing multiple frameworks for building these applications for many years to come. The real issue may lie in deriving value from those investments.

    Survey findings published this week by Pivotal revealed that only 39 percent of global organizations are deploying code on a continuous, hourly or daily basis and only 40 percent deploy code on a monthly, quarterly or annual basis. The survey also found that only 35 percent of developers’ time is spent writing code for new products or features to deliver value, as opposed to maintenance or fixing old code. Also, one-third of U.S. respondents (33 percent) reported delaying application releases more than 11 times due to security concerns, compared to 21 percent globally. Clearly, there is much more DevOps work to be done.

    — Mike Vizard

  • Using Open Source Languages Effectively in the Enterprise

    Using Open Source Languages Effectively in the Enterprise

    Open source languages are part of almost every business these days. In fact, according to Opensource.com, open source will be the driving force behind a great number of technology innovations due to its pervasive use. From development to quality assurance (QA) to DevOps, all kinds of coders have embraced open source languages. In doing so, though, enterprises have given up easier-to-adopt, general-purpose languages in favor of more niche-oriented languages.

    Those who are enthusiastic about open source languages have been contributing to open source language projects and building versions of languages including Perl, JavaScript, Go, Tcl, Ruby and Python. There has been a massive shift in the adoption of open source languages and genesis of new ones in the last 20 years. Even large corporations such as Microsoft, Google and IBM contribute to open source projects that are hosted on GitHub, and Spotify, Dropbox and Reddit are among the big names that use Python.

    This mainstream adoption speaks to the enormous popularity of open source languages. This has brought about the proliferation of new languages co-existing with older languages, which creates more and more challenges for various stakeholders in the software development life cycle (SDLC)—and more tension.

    The tension between these two groups exists because of the gap between their needs. Addressing this tension requires a convergence of the needs of two specific stakeholder groups: coders and the enterprises for which they work. There are ways to fulfill what both coders and enterprises need, create better experiences for coders and make things easier for all stakeholders in the SDLC.

    Enterprises require security, control and compliance. Coders need speed, want to create and crave a frictionless environment. Roadblocks and restrictions need to be removed for coders while ensuring the needs of the enterprise are being met.

    Strength in Uniformity

    What would it look like if you could gain all of the potential benefits of open source languages while still fulfilling coder needs and resolving your enterprise requirements? What if uniform tooling could be provided across open source languages? And what if enterprises could use a single uniform tooling set regardless of open source language? It would solve needs for the coder and the requirements of the enterprise.

    Using uniform tooling, an enterprise’s open source languages can be compiled and installed; dependencies found and installed; and code written, tested and updated complete with security and license compliance needs being addressed. However, tooling currently isn’t uniform across open source languages. And the maturity and best practices of tooling wildly vary. Enterprises create a workaround by creating policies to mitigate for deficiencies in tooling. This workaround is sub-par because it happens too late in the SDLC after threats and issues are introduced into your code.

    Establishing a Single Ecosystem

    The quality that makes open source so useful—its openness—and its lack of controls makes it something of a digital wild west. Fewer restrictions enable faster innovation, but they come at the cost of quality and cohesion for the enterprise. Many of your installed libraries have holes and security threats. Enterprises are faced with time-consuming license reviews to ensure adherence to third-party license rules as well as internal policies restricting certain types of licenses. In addition, license reviews happen at one point in your code’s life cycle versus in an ongoing, automated way. Enterprises are burdened with high administrative overhead and stale information.

    However, there is a different scenario possible. What would it look like for a company to have a uniform and high-standard ecosystem for their package management, with no vendor lock-in, all based on open source? What if a company could be guaranteed the same quality and types of packages for every language they use? What if a company could easily have visibility for what is being used across all of their environments, from concept to development to testing to production? It would be easier for the coder and fulfill the requirements of the enterprise.

    The wild west quality of open source language ecosystems makes them somewhat unreliable; updates and deletions can occur. And there are different package management solutions with differing degrees of sophistication, complexities and required expertise to use. Today an enterprise can easily end up with multiple package management solutions and have different packages of the same open source programming language. There is no single or consistent source of truth. 

    Working with a technology provider is an effective way to mitigate your open source language risks and solve your coder need for speed. A provider can offer more than just support, inlcuding:

    • The appropriate licenses based on usage and policy requirements
    • The right packages for each specific application
    • The best notification and remediation based on Common Vulnerabilities and Exposures (CVE) security threats
    • The indemnification that fits, based on usage
    • The expertise to build you the language distros you need based on usage, environment, security and compliance requirements and applications.
    • The right builds, standardized for all of your teams and ready to go out of the box

    Thriving in the Wild

    Sometimes, using the “right tools” for the job involves coders building many programming languages in an environment. The resulting “polyglot” situation creates benefits as well as challenges. Better products are made, and products are shipped faster, but it’s difficult to build a core competency in a particular programming language. And it’s impossible to centralize support and difficult maintenance requirements.

    What’s needed is a single, uniform tooling set that can work across multiple languages. This makes open source languages easier to use and implement in the enterprise, addressing the needs of developers as well as those of the enterprise. Working with an expert advisor will help you not just survive but thrive in the wild and woolly world of open source.

    — Bart Copeland

  • DevOps Chat: Open Source and DevSecOps with Azi Cohen, WhiteSource

    DevOps Chat: Open Source and DevSecOps with Azi Cohen, WhiteSource

    The security of open source code is one many organizations are grappling with. Add to that the number of times that applications using open source code are updated and the integration issues that come with those updates, and it’s no wonder open source security comes into question.

    WhiteSource thinks it has a solution to the open source code security problem. In this DevOps Chat, we speak with Azi Cohen, head of U.S. operations at WhiteSource, about the issues surrounding the security of open source code and how his company is helping to reduce the problem.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. In today’s DevOps Chat, I’m happy to be joined by someone who I’ve had the pleasure of speaking with several times, but not on a podcast, I believe, and it’s Azi Cohen – “Cone” or “Cohen,” depending how you pronounce it. Azi is head of U.S. operations and a co-founder at WhiteSource Security. Azi, welcome to DevOps Chat.

    Azi Cohen: Hi there. Good morning. How are you doing, my friend?

    Shimel: Good. Happy to have you here with us. So, Azi –

    Cohen: Okay, and, by the way, the name of the company is WhiteSource Software.

    Shimel: Oh, okay.

    Cohen: Yeah.

    Shimel: I apologize. WhiteSource Software.

    Cohen: Yes.

    Shimel: You know, and that’s a good bridge, Azi. Before we jump into today’s topic, which is DevSecOps-related, for those who may not be familiar with the company, why don’t you give us a little background?

    Cohen: Sure. Perfect. So WhiteSource Software was initiated by three of us. We are three partners that were actually working in a different company that was acquired, going through an acquisition, by CA Technologies. And, through this process of due diligence, we found ourselves getting questioned about open-source that was included or not included, you know, in our technology. And that was a very cumbersome process. Took a lot of time and effort. So, not surprisingly, after the three of us been acquired and spent some time acquiring companies, we realized, “Hey, there must be better way to do all these things,” and, a few years later, we started WhiteSource.

    The idea was to allow companies that develop intellectual property using open source – and, remember, we’re talking about 2011, 2012; open source was well-known phenomena or the use of open source, but still not very well-adopted by the large enterprises – so the premise was to help software houses or companies that developed their own intellectual property, using open source, to have a better management and control of the inventory, the legal aspect or the compliance side, and, later on, in security.

    So we started the company in Israel. We got some grants from the Israeli government. We developed a solution and, obviously, we started to focus on companies – you know, at startups and technology companies. And we were doing very well for quite a long time. I think that the big change came somewhere like 18 months ago, maybe 24 months, where we started to feel a growing demand from large enterprises – banks and technology companies, consultants, large chains, health companies. So all those started to use open source and started to look also for a solution, and that’s when we realized, “Hey, there’s a big opportunity here.”

    We went out, raised a lot of money from VCs, including from Microsoft, etc. Started the U.S. operation. And, fast-forward today, we have a very large office here, more than 30 people, in North America. I run the U.S. operation. We’re growing 300 percent year over year. Almost more than 500 clients, from multibillion companies to small ones, and it looks, right now, that demand is not going to drop.

    Shimel: Fantastic. You know, as they say here in America, mazel tov.

    Cohen: [Laughs]

    Shimel: It’s an American –

    Cohen: Thank you for that.

    Shimel: – _____ success story, right? And congratulations to you and the team. But, Azi, you know, sometimes – and, like you, I’ve been in business 30 years – sometimes, it’s better to be lucky than smart. It’s good to be both. But you really – WhiteSource Software and your team has been a little bit of a benefactor of being in the right place at the right time. We live in an age where so much of our – well, everything is software and applications, but so much of our applications are built on open source component, primarily, right? A majority of –

    Cohen: Absolutely. That there is a Gartner report that states that something like 40 to 60 percent of the new web applications consist of – is consisted of open source and this is just going to grow. Right? So it’s not going to stop there. And we definitely see that by our biggest clients. We see them starting when they have something like 20 percent of their code being open source, very quickly reaching to 30, 40 and more, right?

    So this is not something that is going to happen, and I think there is a very good reason for that. If you look at large ITs today – banks, etc. – you know, the CIOs are being asked to create more and more innovation. Someone wrote an article about it. Something like that they’re required to generate something like 25 percent of new ideas and new application or, if you want new lines of code, you know, 25 line of code, year over year, but they don’t get 25 percent more people to do it. Right? They just get 2, 3 percent. So reuse instead of build is the most obvious solution, and that’s why we’re not going to see that percentage dropping, but going higher and higher.

    Shimel: Oh, and – but it makes good sense, right? So much – you know, when you look at the average application, so much of it is rinse and repeat, right? Sending an e-mail, firing off an e-mail or registration, opening a window. So many of – there’s no sense reinventing the wheel of these things _____ _____ –

    Cohen: Oh, absolutely.

    Shimel: You know, when you look, there’s so much Java script reused, there’s so many Java components reused. There’s so much of these open source reuse – like you say, it’s only gonna be more and more, as these libraries and repositories get bigger. But that begs the question, Azi, of it doesn’t make us more secure, necessarily. And, as a matter of fact, some may argue it makes us less secure. What’s your position?

    Cohen: Well, it’s a great question. You know, and, obviously, when you have one component being used by millions, it’s just an opportunity for attacker to find a way to hack it, crack it and now they have thousands of companies that may be vulnerable to this one, right? And then, for them, an open door to get into those accounts. So what we actually see is that, with the fact that more and more open source is being used, on one end, we have attacker trying to exploit those open source components and we have seen some cases in the past, right?

    In the same time, the community tries to find more vulnerabilities and fix them as fast as possible, but, if you look at the DevOps guys, this create a huge problem because, think about it, on one hand, they use more and more open source; on the other hand, the community, which is very active, is finding more and more vulnerabilities in those open source and provide fixes, right?

    So now the DevOps guys have more stuff to deal with, a larger inventory to track and check and validate, but, on the other hand, we know that the attacker, that know that these guys will patch those vulnerability very quickly, try to hit them faster and faster. So DevSecOps or DevOps guy have more stuff to do in less time. So the only solution is by automation, right? The only solution is by some control that will let them know what’s good, what’s bad, and provide alerts when something bad is happening or when new vulnerability that is – that they are exposing the inventory is _____ _____.

    Shimel: Yep. Absolutely. And you know what, Azi? This is – what you just described, yes, it’s 100-percent dead on for DevSecOps, but it also describes so much of what we are seeing in software development in general. If the machine, if the factory is gonna run, at the optimum speed, we must automate so much of this, right? Because, otherwise, it just can’t keep up and security is certainly no exception. No exception. _____ –

    Cohen: Absolutely. And another thing here is that you have to detect or try to stop bad things from coming in at the gate and not later, right? Because every step later – so it’s automation but also automation at the front of what’s called shift left, right? As early as possible in the development cycle. And then, at WhiteSource, we do exactly that.

    Shimel: Yep. So this begs the question, though, “Sounds wonderful. Let’s all do it. Why aren’t we more secure? Why aren’t more people doing it? Is it really that easy?”

    Cohen: I think it’s mostly a matter of awareness and perception as well. So, firstly, when I meet with CIO, CISOs, they don’t – in many cases, they don’t understand what level of adoption of open-source they have in their environment. Their perception is that, in many cases, that they use only 10 percent or 15 percent of the code, is open source. The reality is it’s higher.

    So perception of the problem is one thing, and top managers in many places don’t understand that the amount of open source being used right now is larger than what they have, but the other thing is that, you know, the perception is that standard tools, like application security testing tools from IBM or from Checkmarx and from other vendors, right, are solving the problem. You know, since they scan the proprietary code, then most likely scan the open source as well, but that’s not true. That’s not the case.

    And the last thing is that, once more awareness or, if you want, education – the assumption by most managers is that open source behaves like the proprietary code, right? You use a scanner. You test the open source. You find vulnerabilities. Somehow, you either fix them or not, and they’re fixed. It’s a one-off. What they miss is that open source is a living thing. You may have a clear open source component that are using now, which is fine, but then, month later, there could be a vulnerability in it, right? You have to be able to track it later on. It’s not a one-off test and gone.

    A good example is Apache’s Struts No. 2, right? A year ago, the whole world was astonished by this Equifax thing that was created by an attack to Apache Struts. Everyone mostly likely fixed it by today. And guess what? Three days ago, a week ago, a new vulnerability in Apache Struts No. 2, which was fixed, was discovered. And that’s not going to be the last one, right? So open source is a living thing, vulnerabilities are coming and going, and you have to keep track.

    So I believe the top managers – CIOs, sometimes CISOs – are not aware of all those effects that came out there, with more open source, right, that the current tools does not solve it. And, finally, that they need a tool that is designed to track changes in the security of their open source inventory along the time.

    Shimel: Exactly. I mean, you talk about Struts 2, which is sort of the poster child here because of all the press and notoriety that Equifax got. And I saw a presentation by – I forgot what company it was, but what really surprised me, Azi, is, even after we knew it was bad and you had to patch it, you had to upgrade it, the amount of people who were still downloading and using the old version – it dropped off from maybe 80,000 a month to 70,000 a month. Right?

    Cohen: Awareness, right? And, by the way, these numbers are changing, so you may not know, but we just released a tool called “Vulnerability Checker.” It can be downloaded from out website, whitesourcesoftware.com, and, basically, it will check – it will do an automatic check to check, for clients _____ – people that are interested whether their systems are affected by Apache Struts 2, right? So for those that are aware and would like to know whether they have some issues with that right now, they can download it free and check very quickly their system and find whether they are affected or not.

    Shimel: Yeah. But this is also the future of where companies need to be. They need to do this and then they need – you know, Azi, I remember I was selling vulnerability management and patching, oh, maybe 2005. I was talking to one of the CIOs. They had three CIOs at Citibank. This is before it was called “Citi”; it was “Citibank.” They had three global CIOs. I showed them a system that would scan for vulnerabilities and, if there was a known patch for the vulnerability, it’d integrate it with a patch manager that would automatically – that would patch these up.

    Cohen: Sure.

    Shimel: And he said, “This is great, but, Alan, we don’t just install a patch ’cause we found a vulnerability. Before we can install a patch, we have to do regression testing on all of the applications. We run about three months behind.” So, literally, there was a three-month cycle by the time they would patch a known vulnerability that they found. And, yeah, I’m not saying it’s that bad today, but that sort of mentality, that approach, just doesn’t work at the speed of business today.

    Cohen: You’re 100 percent right. And I bet that Citi today have hundred times more vulnerabilities per application than they used to have at those days, but this is an important point because we face that any of our large clients – and, actually, we just came up with a very, very smart solution for that. So we know, as you mentioned, that it takes them a long time to patch, right? And we know that they have thousands of vulnerabilities sometimes, and they need to know where to put their time, right? Especially if it takes longer time.

    So we came up with a tool called “Effective Usage Analysis,” and the idea is very simple. When a developer picks up a new open source component, this component usually come with 10 or 15 different functions. Each one of them may have some vulnerabilities, etc., so this entire package could come with, let’s say, 10 different vulnerabilities. But the developers will use only one or two functions, and, therefore, you’ll be exposed only to two or three out of those 10 vulnerabilities. So Effective Usage Analysis is a new module that we release. It runs over the code and identify how the developers use the open source and, therefore, clean out all the non-relevant code.

    So, for this kind of – for the Citis of the world, that have thousands of vulnerabilities, Effective Usage Analysis will drop the number of relevant vulnerabilities by 70 percent – seven-zero. These are the statistics. And now they’ll have only the most severe 30 percent where they can and should spend those three months in order to fix them, on the road to get a better security solution. It’s huge. This difference is huge. We get a lot of good feedback from clients that are testing that. It really helps them to make sure that every hour that they spend is much more effective.

    Shimel: Excellent. And this thing you can also get at WhiteSource Software?

    Cohen: Absolutely. Yeah. It’s a new model that we just released.

    Shimel: And what’s the name of it again?

    Cohen: Effective Usage Analysis.

    Shimel: Effective –

    Cohen: EUA.

    Shimel: – Usage Analysis. EUA.

    Cohen: Yep. Yeah.

    Shimel: Got it. Well, Azi, as I mentioned to you before we started recording, the 15 minutes here goes very fast.

    Cohen: [Laughs]

    Shimel: We’re already over 15 minutes. We could probably talk all day about this, but we’re gonna have to call an end to this episode of DevOps Chat. But maybe we’ll have you back on soon and we can continue the conversation.

    Cohen: Sure. Thank you. It’s always a pleasure talking with you, Alan, so I’m looking forward to it.

    Shimel: No, it’s my pleasure, Azi. I feel like we could sit and talk and go all day about this, but we’ll call it a wrap. Azi Cohen, a co-founder and chief of U.S. operations for WhiteSource Software, thanks for being our guest on this episode of DevOps Chat.

    Cohen: Thank you for the opportunity, Alan. Always a pleasure.

    Shimel: Pleasure. This is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • CloudBees Extends CI/CD Scope, Reach

    CloudBees Extends CI/CD Scope, Reach

    CloudBees, at its DevOps World | Jenkins World 2018 conference this week, unveiled a broad strategy to extend the reach and scope of continuous integration/continuous deployment (CI/CD) platforms based on the open source Jenkins software.

    Company CEO Sascha Labourey said CloudBees Suite will provide the equivalent of a customer relationship management (CRM) application for software delivery. That approach will not only accelerate application development processes, but also provide application stakeholders across the enterprise with more visibility into DevOps processes. For example, business executives are demanding more visibility into DevOps processes as the organization begins to appreciate how dependent it is on the timely delivery of software, Labourey said.

    Rather than buying isolated components of a CI/CD platform, the CloudBees suite provides a single pane of glass through which all the elements of the platform can be managed. That capability is critical because it enables an organization to start with one element of a CI/CD platform that, over time, can be expanded frictionlessly as the organization becomes more comfortable with DevOps processes.

    Labourey said it’s clear the CI/CD platform is the hub around which those DevOps process revolve. The CloudBees Suite includes CloudBees Core to unify the management and governance of pipelines, which includes limited availability of the Kube CD for extending the CloudBees platform to Kubernetes clusters. In fact, Labourey noted that Kubernetes is rapidly emerging as the foundational element of a federated approach to CI/CD in the age of microservices.

    CloudBees also announced an alliance through which Lenovo will provide IT organizations a turnkey set of servers running instances of CloudBees Core on the Red Hat OpenShift application development platform. As DevOps continues to evolve, Labourey said, organizations want to reduce the amount of time it takes their IT teams to deploy the infrastructure required for a modern application development platform.

    Another core element of CloudBees Suite is CloudBees DevOptics, a software-as-a-service (SaaS) application that provides visibility and insights into value streams and operations as well as continuous reports on the four key DevOps metrics. CloudBees DevOptics will provide the raw data the company will rely on to apply artificial intelligence (AI) in the form of machine and deep learning algorithms to the CloudBees CI/CD platform, Labourey said.

    The two remaining core modules of CloudBees Suite are CloudBees CodeShip, which enables organizations to jump start projects using a CI/CD as a Service offering, and CloudBees Jenkins Support, which provides users of the open source Jenkins platform full support. CloudBees is also making support for instances of Jenkins available as a standalone subscription service.

    It’s clear that CloudBees is trying to extend the reach of its widely employed CI/CD environment not only to new platforms, but also to new users. As digital business processes continue to proliferate across the enterprise, there is now a lot more at stake whenever an application development project is delayed. While such delays may be inevitable, the degree to which organizations might be surprised by those delays can be reduced sharply when everyone in the organization is operating on the same DevOps page.

    — Mike Vizard

  • Mirantis Modeling Tool Extends SDI Scope and Reach

    Mirantis Modeling Tool Extends SDI Scope and Reach

    Mirantis has added a modeling tool to its portfolio that enables users to allocate IT infrastructure that has been distributed across multiple data centers to a common set of workloads.

    Company CEO Adrian Ionel said the latest edition of the Mirantis Cloud Platform (MCP) for building provide clouds on OpenStack or Kubernetes platforms now includes a Mirantis Infrastructure Model Designer tool that makes it possible to manage IT infrastructure residing in multiple data centers as though they were one logical resource. In effect, slices of distributed data centers can be allocated to run specific classes of application workloads, he said.

    The Mirantis tool is based on open source software spanning Cookiecutter, Reclass and Salt projects that Mirantis is employing to enable users to apply management templates across multiple distributed data centers. The goal is to make it possible for IT organizations to employ a software-defined framework that makes it easier to not only manage distributed IT environments, but also change the configuration of those environments as the nature of application workloads change over time, Ionel said.

    The Mirantis modeling tool provides a declarative approach to managing software-defined infrastructure that doesn’t require IT operations teams to learn how to program, he added.

    Ionel said that as IT organizations invest in IT infrastructure, they need to deploy multiple classes of application workloads on the same systems. Each of those application workloads has distinctly different attributes and requirements. For example, a big data application running on Hadoop today has different infrastructure requirements than an analytics application infused with machine learning data that might be deployed tomorrow. That said, most IT organizations won’t be able to replace IT infrastructure as application workloads evolve, he said, noting the Mirantis tool provides a means to easily reconfigure IT infrastructure from a central location without requiring IT personnel to be present in each local data center.

    Virtualization of servers and now storage and networks is a concept that has now permeated data centers for decades. Mirantis is effectively taking that concept to its next logical conclusion by making it possible to maximize utilization of data centers. In fact, Ionel noted, templates can be configured to prioritize the running of different workloads on the same infrastructure.

    As software-defined infrastructure (SDI) continues to mature, it’s becoming apparent that data centers soon will be managed at much higher levels of abstractions than they typically are today. Instead of trying to navigate individual compute, storage and networking silos, IT organizations will be able to manage data center resources on demand. The implications of the level of automation go well beyond simply enabling IT organizations to be more agile—the entire organizational structure of IT organizations will need to evolve.

    Obviously, organizations that have embraced DevOps are further down than the SDI path than most. But as SDI continues to be able to automate IT infrastructure at levels of unprecedented scale, it’s clear there’s still a long road ahead in terms of how just how extended those DevOps processes can become.

    — Mike Vizard

  • Best Practices for Your SaaS Laravel Application on AWS

    Best Practices for Your SaaS Laravel Application on AWS

    It is not easy to subsist in a modern cloud ecosystem. However, there are solid principles that will help you to build a perfect AWS architecture for your Laravel application, including the 12-factor methodology, design applications with a stateless approach and decoupling service components.

    I’m sure you are adopting many of these principles already. However, I will cover merely the relevant to the AWS Laravel architecture and AWS Auto Scaling to maximize infrastructure robustness.

    12-Factor App Methodology Key Principles

    Application config files: These should be outside of the codebase, and these config files are replaced with environment variables, i.e., Db connections, secrets, environment, hosts, IP, etc.

    Application dependencies: These shouldn’t be in your codebase; instead, use a dependency management tool to declare your large dependencies and libraries required from the server. i.e., Gemfile, site-packages, pom.xml, manifests, etc.

    Use a control versioning system (CVS): It is necessary to integrate the Git workflow. i.e., Github, bitbucket or AWS CodeCommit.

    Stateless applications and processes: It’s crucial that your application doesn’t store any data in the local file system or is dependable from a persistent state in the application or server. In other words, the application/server can be turned off and re-created without losing any data. Only persistent data is stored in databases or backend services.

    In case of application failure, splitting components as much as possible and make them independable to others will result in an easy analysis and isolated issue.

    Immutable infrastructure: Instances shouldn’t be modified after provisioned, and there should be a standard base image (AWS AMI) that is regularly updated and patched. As a result, you’ll get an AWS auto-scaling that works smoothly, with fewer deployment failures and consistent infrastructure.

    Dev, test and production parity:  It’s crucial that these environments should be as similar as possible, regarding software, libraries, database data and code. Furthermore, it’s possible to close the gap across all environments using a CVS, repeatable infrastructure and continuous integration/delivery (CI CD).

    CI/CD: As the application and traffic grow, you need to implement a mechanism to release code to your different instances and enterprise environments. It is essential to design a continuous delivery workflow to improve development productivity with scalability, multiple environments and a distributed architecture.

    Evidently, these architecture design principles are part of the DevOps culture, which is in the plans of many CTOs, engineering directors and VPs.

    10 Best Practices to Scale and Architect Your SaaS Laravel Application on AWS

    Here are what we consider to be the 10 best practices to design, architect and build your PHP Laravel application to help you resolve issues around how to architect and scale a Laravel application, and which technologies are relevant for your product to align them with your PHP Laravel codebase.

    Practice No. 1:  Amazon S3

    In my perspective, Amazon S3 is the second component that boosted the evolution of the cloud, just behind the pay-as-you-go model with cloud scalability. Amazon S3 is an unlimited cloud storage with superb capabilities, including 99.99 percent of durability and high availability, object-based storage acting as an API and with the ability to host static websites based on HTML, Angular and React! Amazon S3 Cloud storage can be a serverless application without much effort.

    Amazon S3 is reliable, scalable and secure with no real configuration needed.

    The first step to scale and architect your Laravel application is to separate all static content (media, images, video, docs, etc.) to Amazon S3. This split allows distributing the application’s requests in parallel, dynamic content served by the EC2 instance (web server) and the rest with Amazon S3. This is a DevOps and development effort, where all static content on your Laravel project is pointed to the Amazon S3 endpoint.

    Technically, you need to move your actual content into Amazon S3 buckets, set the correct IAM roles/permissions to allow read access, and configure your Laravel driver to point to Amazon S3. (Here are more details about how to integrate Amazon S3 with Laravel.)

    Amazon S3 can host static websites and front-end applications (HTML, Angular, React and more) in a manner that is fully scalable, redundant and serverless. From my experience, I recommend to host your static websites on Amazon S3. The presented practice can be performed with a few steps and no servers needed (Serverless).

    Practice No. 2:  Horizontal Scaling with AWS Auto Scaling (Load Balancer)

    The next AWS component in the pipe is AWS Auto Scaling. This fantastic feature revolutionized the scalability paradigm. Before AWS Auto Scaling, there was merely manual scaling, and reacting to different traffic events was difficult to converge and caused several failures.

    It’s vital to consider that AWS Auto Scaling is not the same as a load balancer; it’s common to confuse these two terms.

    AWS Auto Scaling scales dynamically behind a load balancer (AWS Application Load Balancing), which is defined by a set of scaling policies (thresholds/limits) that must occur to scale up and down. The instances can scale up and down based on predefined criteria for CPU, RAM or any other instance metric, allowing you to save money and unneeded AWS resources.

    Primarily, to deploy AWS Auto Scaling you need to:

    • Set up AWS Application Load Balancer
    • Define a threshold for triggering the autoscaling event on AWS CloudWatch
    • Determine a min/max servers amount
    • Set an AWS Auto Scaling group, AWS Auto Scaling launch configuration pre-configure O.S. with an Amazon Machine Image (AMI).

    Practice No. 3: AWS RDS Aurora with Replication

    Amazon RDS, it’s a database managed service, which requires minimal maintenance and is compatible with MySQL, PostgreSQL, Oracle and more. The RDS is a self-maintained database with a pre-configured database, software updates, patches and automated backups. To scale and cluster an Amazon RDS, first you need to enable RDS replication feature, which grants your RDS the capacity to create replicas and establish master-slave relationships with those replicas, similar to MySQL/PostgreSQL replication; this can be achieved with just a few clicks. You can enable RDS Aurora with a replica (slave database), which this replica can be allocated in other availability zones to ensure more availability.

    Aurora RDS Replication

    Similarly, Amazon Aurora is the high-performance database from AWS, which combines high speed, high availability and performance. According to AWS, Aurora is 5X faster than a standard MySQL or 3X faster than PostgreSQL.

    Amazon Aurora is the high-performance database from AWS, if you are planning to improve your database throughput. You should definitely consider Aurora.

    Hint: AWS Aurora with replication and/or Multi-AZ availability can be expensive, take precautions with your cloud hosting budget. You can review our “AWS Cost optimization checklist” to reduce your AWS billing.

    Practice No. 4: Application Load Balancing (Laravel Load Balancer)

    Some years ago, Amazon introduced the Application Load Balancing (ALB), which is a layer 7 LB. It has multiple benefits including the capacity to balance requests by domain/URL and not just by port/protocol. It also supports the inclusion of multiple SSL certificates. It is significantly cheaper than the ordinary Load Balancer service, and it’s billed by request. One relevant fact about ALB is that you don’t need multiple load balancers for integrating different APIs/domains.

    That being said, I recommend to architect your Laravel application based on an ALB Auto Scaling integration. It’s a must to have a load balancer enabled to scale and grow your SaaS Laravel application. You can balance your HTTP/https services, APIs and any web socket. Lastly, It’s evident that the ALB was natively built for microservice environments with Docker, AWS ECS and Kubernetes, but it can also be used with a monolithic approach, as presented on this architecture.

    Practice No. 5: CloudFront CDN

    Now that you have Amazon S3 running in your application, we need to introduce CloudFront CDN in front of Amazon S3 and save bandwidth!

    Amazon CloudFront CDN is an amazing component with numerous features to highlight and collaborates commonly along with Amazon S3. Amazon CloudFront, it’s a content delivery network aimed to cache content, distribute requests, serve video content and much more features.

    Some CloudFront capabilities:

    • This CDN is globally distributed, consequently, traffic is routed to the nearest edge location helping to improve the user experience and speed.
    • It helps improve application speed by caching static/dynamic content coming from the Amazon S3 or EC2 (origins).
    • It helps reduce AWS bandwidth costs coming from the amazon s3 due to its caching magic.
    • Similarly, It’s used as a video hosting solution for media/video streaming.
    • It’s built to improve application performance and scalability by granting low latency.
    • CloudFront can help to secure your backend instances and filter common botnets/DDoS attacks. This is achieved with the help of an AWS WAF.
    • It decreases the load on web instances, enabling you to use less AWS resources.
    • It has support for security certificates (SSL/TLS).

    So, what do you need to know to integrate your Laravel application with CloudFront CDN? Mainly, it’s recommended to have an additional subdomain (C-Name Record) for this CloudFront edge location, i.e., cdn.company.com. Also, as discussed, static content should be placed on an Amazon S3 bucket and Cloudfront will pull the data from the origin (S3 bucket).

    Next, you need to create a CloudFront distribution where all content will be distributed across the edge locations; thus, end-user content will start getting cached. And that’s it—it should take you a few hours to set it up, considering you have your Laravel code-base pointing to Amazon S3.

    Practice No. 6: Amazon VP

    Amazon Virtual Private Cloud (VPC) is a logical network on the AWS Cloud; it lets you build multiple isolated logical networks inside your infrastructure. Creating a VPC network as well as robust subnets is essential to growing architect and structure applications in multiple groups/departments. AWS Networking (Amazon VPC) has various features including subnet creation, route tables, own IP ranges, network ACLs, AWS security groups (network firewall), network gateways, hardware virtual private network (VPN) creation and more.

    When deploying a VPC for your SaaS Laravel application, you must ensure that web instances, databases and backend services are all included on a private subnet, and that the ALB is added on a public subnet. With this network topology, consider deploying a VPN to access your private network.

    Your SaaS Laravel application can be transformed into a superbly secure logical network, complying with one of the multiple PCI/HIPAA/FedRamp requirements.

    Practice No. 7: AWS ElastiCache (Redis and Memcached)

    Introduce AWS Elasticache to your Laravel application to provide higher throughput and lower latency retrieved from your database.

    AWS ElastiCache is a caching and data storage system that is fully scalable, available and managed, aimed to improve application performance of distributed cache data and in-memory data structure stores. It’s an in-memory key/value store for Memcached and Redis engines. With a few clicks you can run this AWS component entirely self-managed.

    A few benefits of AWS Elasticache:

    • It reduces workload on the backend (database and processing)
    • It improves application speed by caching data.
    • It helps to scale and architect modern applications.
    • It manages and stores your application session.
    • It reduces low latency.
    • It can scale from one to many nodes.

     AWS ElastiCache use cases:

    • Real-time transactions.
    • Real-time chats.
    • Analytics and BI.
    • Session store (session management).
    • Data caching.
    • As a queuing system.

    The difficulty here is knowing how to use AWS ElastiCache with your application functionality and what application modules can be handled by your caching system. The integration from your PHP Laravel framework to the AWS component is a three-step process:

    1. Deploy AWS ElastiCache and identify your Redis endpoint and port.
    2. Deploy predis/Redis package via Composer
    3. Connect your config/database.php file with your Redis endpoint

    Thus, the dev team must figure out what pieces of your application can be used with AWS ElastiCache to improve high performance and throughput.

    Practice No. 8: Route 53

    Switch from Godaddy DNS to AWS Route 53.

    Your DNS might be managed by GoDaddy, but it is a vital practice that the entire DNS domain is controlled by Route 53. This AWS component can act as a DNS load balancer to route traffic according to latency, and helps to scale modern cloud-native applications.

    Amazon Route53 is a modern DNS manager service designed to scale and improve high availability from the DNS perspective. Similarly, it has the ability to act as an API and can interoperate with your API Laravel application. It also introduces the agility necessary to deploy scalable applications and useful to integrate to Amazon EC2 instances, Elastic Load Balancing (ELB) and Amazon S3 buckets. I highly recommend that modern Laravel SaaS applications be migrated to Amazon Route 53—not just the application, also the DNS records and domain name. Here’s more on how to migrate your Godaddy DNS to Amazon Route 53.

    Need more redundancy and improve response? Create a new environment in different AWS region and deploy AWS Route53 with routing policies.

    Some Amazon Route53 features:

    • Health checks. Route53 can monitor your applications for outages or downtimes. Also, it can be used as a monitoring system. (just a basic one; it won’t replace a monitoring system.)
    • DNS failover routing policy. As the name states, you can obtain a failover solution on the DNS level, separating your SaaS PHP application on two environments, primary and backup waiting to jump in case the primary fails. This brings us more resiliency and high availability.
    • DNS latency routing policy. This policy directs traffic requests to the lowest latency between the end user and the application environment. As a result, application speed and UX improvements.
    • Geographic routing policy. This routing policy lets your requests be routed to the same physical region where you are located. Similar outcomes from the previous point, degrade latency.

    A common misunderstanding is that DNS Failover (Amazon Route53 Failover) is not the same as load balancer failover, Haproxy failover or Heartbeat.

    Practice No. 9: Why Not AWS EFS?

    At Clickit, we used to architect SaaS Laravel applications with AWS EFS, but using EFS for sharing code across multiple instances behind an AWS autoscaling slows the application performance and introduces another network layer to the scalability equation. AWS EFS was a promising NAS replacing NFS, but evidently, when working with remote storage shared within a cluster of instances, there is no way to avoid the network latency. However, AWS EFS can be used for multiple activities, including disaster recovery, improved NFS solution and elastic file storage.

    It’s not recommended to include AWS EFS in your AWS architecture’s equation, due to the network latency that can cause serving your code base or static content.

    Practice No. 10: Scaling with Lambda

    AWS Lambda

    Over the past 10 years, AWS has revolutionized the cloud, with its pay-as-you-go model, auto scaling, DevOps, microservices and now serverless (Lambda). In 2014, AWS Lambda was released with the premise to run code without servers, introducing the paradigm of serverless applications with minimal IT operations (NoOps) and jumping all *aaS ecosystems up to executing code per events only when needed—again, fully scalable, redundant and with the pay-per-use pricing model. With Lambda you are charged for the milliseconds consumed, number of requests and compute. More info on the Lambda AWS official resource is here.

    Lambda is 100 perent no Operations (NoOps).

    Some Lambda use cases:

    • Serverless web applications. Lambda can be handled to process the application logic of any front-end application (Angular, react and HTML)—for instance, sending emails or processing forms requiring a Laravel backend process/job.
    • Disaster recovery and backups. Planning to script your backups inside an EC2 instance? Why don’t you move your bash scripts to a python Lambda function?
    • Lambda and API gateway. Lambda is commonly combined with AWS API gateway. Any logic that is required by your API gateway is handled by lambda—for instance, to process persistent data to RDS or JSON calls coming from the AWS API gateway.
    • Process hot data. Lambda can transition data from Amazon S3 to Kinesis, DynamoDB or RDS. Another good use is for recording, processing and converting video files composed of AWS Elastic Transcoder, S3 and Lambda.
    • Scheduled events, workers and jobs. Lambda can replace your cronjobs, workers and long-processing jobs that are hosted on a single EC2 instance as a cronjobs/workers.
    • Build IoT and mobile backend. Develop your entire digital product (IoT and Mobile) with serverless and NoOps, composed of AWS Lambda, AWS API Gateway and the mobile hub.

    How to integrate your Laravel PHP application with Lambda is up to your imagination. But you can initiate with the presented Lambda scenarios.

    Why Did I Not Include AWS Beanstalk?

    There’s one component that we did not outline about. AWS Beanstalk is a platform-as-a-service (PaaS) platform that lets us build, deploy and scale cloud-native applications with minimal maintenance. AWS Beanstalk is comparable to Heroku, but for the AWS platform. It has his pros and cons, and in this article, we established a different approach without AWS Beanstalk due to various indicators including slow deployments, custom configurations that are challenging to achieve and difficult to maintain (stack upgrades) and complicated troubleshooting due to lack of flexibility in the AWS infrastructure.

    What Have We Learned?

    We explored how AWS can be the key to the application success and how AWS can help serve a million users by an eloquent architecture with the 10 AWS practices, 12-factor methodology and DevOps Automation. We have learned crucial AWS components to scale and architect Laravel SaaS applications, which are also applicable to the enterprise. Additionally, we described the essence of each AWS component, uses cases and an overview of how to tackle each principle. By applying these measures to your web application, you are systematically converting a cloud-native application. Finally, once on board  the AWS cloud, you have joined the journey to the continuous digital transformation that the AWS cloud is pulling us by inertia.

    — Alfonso Valdés

  • Using Laravel and AWS: What You Need to Know

    Using Laravel and AWS: What You Need to Know

    Most likely, you have heard about and Laravel, the open source PHP framework, and you might be planning to go to the next level to modernize your PHP Laravel application. AWS offers a number of features to help organizations scale to support millions of users, not to mention the agility and cost benefits associated with a cloud infrastructure. These features and capabilities are the compelling promoters to transform your application into a high-performing and resilient PHP Laravel application.

    In this article, I will describe how to architect your software-as-a-service (SaaS) Laravel application with high-level scalability standards on AWS to help you understand what is required and discuss the considerations and action items to gain business value and resiliency. We chose the AWS cloud since is the most mature infrastructure-as-a-service (IaaS) provider and makes things easier to innovate; however, these practices can be applied to any cloud platform.

    I also will explain why AWS is a vital option to scale and grow your SaaS Laravel application and present the current/future enterprise architecture. In part two of this series, I will discuss the importance of the 12-factor app methodology and multiple lessons to include in your strategy when architecting on AWS DevOps.

    The Value of Migrating Your Laravel App to AWS

    In an article I wrote for my company blog on running the digital transformation on AWS for your enterprise or web application, I explained the business benefits that brings the AWS cloud adoption, including a reduced IT labor force, pre-configured services to achieve faster implementations and minimal downtime, due to the repeatable and flexible infrastructure. The cloud is an essential environment to scale SaaS Laravel applications—in there, you can decouple your architecture into multiple service pieces, including cloud storage (Amazon S3 and CDN) and automatic scaling EC2 instances (AWS Auto Scaling), and integrate various SaaS/platform-as-a-service (PaaS) AWS components for your modern, cloud-native application. Also, if you are planning to move to the AWS cloud, you could use this AWS Migration Checklist to prepare for your journey.

    “Web Applications and enterprises need to transform, they need to transform to a continuous transformation, and the cloud is the key.”

    – Stephen Orban

    I really enjoyed this phrase from AWS’ Stephen Orban, because you’re not only transforming your application; once on board the AWS cloud, you are in an infinite journey of continuous innovation: pay-as-you-go, microservices, serverless and so on.

    Laravel Architecture on Docker and Microservices

    Throughout the AWS cloud journey, there have been multiple disruptive evolutions, and one of them is the microservices, although, I won’t cover the microservices (Docker) approach. As a first step to transforming your application toward a cloud-native application, start with a monolithic approach. As your application matures and user base increases, I suggest jumping into a Laravel microservice approach, i.e., dockerize your Laravel PHP product using Docker, AWS ECS, Kubernetes or AWS Fargate. I’ve found many digital agencies that are adopting the AWS Cloud and DevOps practices with Docker/Serverless strategies and are getting overwhelmed with these sophisticated technologies, which has led to project failure because they were not ready to this stage.

    Here’s how to avoid that: Grow gradually.

    However, if your Dev team has enough experience with Docker and microservices, I wouldn’t hesitate to architect with microservices. This will be covered in the next article in this series, “Microservices with Laravel, Docker and AWS ECS.”

    Who is This Article For?

    Whether you are kicking off an MVP app on Godaddy/Hostgator, deploying Laravel on AWS with basic principles or ready to jump from hundreds of users into million users, this article is for you and will help you in your Laravel architecture on AWS.

    Laravel for Large-Scale SaaS Architecture on AWS

    So, let’s start by making clear what do you most need to scale a Laravel application on AWS.

    The diagram below illustrates how a next-generation Laravel application should be architected with the full range of AWS DevOps components. Each piece mentioned in this AWS stack is highly elastic, scalable and resilient.

    AWS Laravel Architecture Diagram

    AWS Auto Scaling and Load Balancing

    Initially, the dynamic traffic comes from AWS Route53, which will route all requests to the Application Load Balancing, which the AWS ALB will load balance across a fleet of EC2 instances ( 2…N Instances). This fleet should “scale” horizontally according to the traffic demands or the AWS CloudWatch metrics.

    Amazon S3 and CloudFront CDN

    All static content including images, videos and HTML will be hosted on Amazon S3, the cloud storage with infinite storage and elasticity. In front of Amazon S3, we will compound AWS CloudFront to cache the entire static content and reduce bandwidth costs. Integrating this pair of components is crucial.

    AWS RDS Aurora (Managed Database Services)

    The database data should be placed on AWS Aurora or RDS and AWS ElastiCache (Redis) for session management and cache user data. These AWS components are elastic and scalable, which helps to design the AWS Well-Architected framework with the highest fault-tolerance and resiliency.

    Amazon VPC and Networking

    In the AWS Networking level, we propose AWS VPC with a public/private enterprise network. Following PCI and HIPAA practices, there should be a VPN encapsulating the Laravel application within the private AWS enterprise network. Also included should be an AWS VPN connection and OpenVPN service to access the private network to your multiple Laravel environments.

    Route53

    From the DNS perspective, Route53 is needed to manage the application domain, DNS scalability, routing latency and more features to reduce failures.

    AWS Lambda

    This serverless component will be used for async jobs and backend scripts to minimize load in your AWS Auto Scaling cluster.

    We will explore these AWS components substantially in detail, later in the third article of this series.

    Web applications that can fit within this architecture:

    • API Laravel applications
    • Mobile backend applications
    • Laravel enterprise applications: CRMs, ERPs and back-office systems
    • SaaS Laravel applications
    • Front-end applications. i.e., Angular, React, Vue.js or any HTML site
    • ANY web platform: Python, Node.js, Ruby, PHP, Zend, CakePHP, Yii and Symfony

    A word of warning: Don’t use Cpanel for any web application. It is not recommended to scale as it can slow down your application performance.

    — Alfonso Valdés

  • Netifi Rises to Microservices Integration Challenge

    Netifi Rises to Microservices Integration Challenge

    Netifi this week launched an integration platform based on the open source RSocket communications protocol to replace HTTP ad REST application programming interfaces (APIs) as the mechanism for connecting microservices. RSocket was originally created by Netflix and is now being strengthened via contributions from Netifi, Facebook and Pivotal Software for use within enterprise IT organizations.

    Fresh off raising $2 million in seed funding, Netifi is also committing to support a community edition of RSocket later this year.

    Company CEO Robert Roeser said the Netifi platform is designed to make it easier to build microservices and interconnect them. Most of those microservices are being built using Docker containers, but Roeser said that, as part of a polyglot approach to integration, Netifi is leveraging RSocket to connect microservices built using a variety of runtimes as well as provide access to legacy monolithic applications. The Netifi platform can be deployed on-premises, in a public cloud or in a hybrid fashion.

    Roeser said RSocket was born of necessity at Netflix because the number of microservices that needed to be interconnected at scale was simply too complex a task using HTTP and REST APIs. Soon after, Facebook also started employing RSocket and now Netifi and Pivotal are making contributions designed to make Rocket more accessible for traditional enterprise developers. In the case of Netifi, that means providing mechanisms to both discover and advertise microservices and provide a layer of abstraction that shields developers from the underlying complexity of the network underlay, he said.

    As applications based on microservices become more widely distributed, enterprise organizations tend to become more intimidated by the challenges associated with managing them at scale. Traditional enterprise IT organizations don’t have access to a small army of software engineers to solve the problem. As a result, many of them retreat to building monolithic applications in which all the services that need to be accessed are baked into the application itself. They typically sacrifice scale and flexibility in favor of a construct that is both familiar and easier for them to navigate, Roeser said.

    The challenge Netifi and other supporters of RSocket will face is the considerable amount of inertia surrounding REST APIs and HTTP. Several generations of developers now consider REST APIs to be the default mechanism for connecting various applications together. The issue many of them will need to wrestle with is the extent to which the rise of microservices breaks that integration construct. A shift away from REST APIs also could have significant implications regarding how services are exposed externally, how pipelines are constructed within DevOps environments and other factors.

    It remains to be seen whether integration platforms based on RSocket or some other approach ultimately makes microservices more accessible to enterprise IT organizations. But significant resources now are being poured in to solve the problem, many of which leverage contributions of companies, such as Netflix and Facebook, that already rely on thousands of microservices to deliver a broad range of cloud-native applications.

    — Mike Vizard