Well hopefully you're all aware that the vote has completed and the winner is ... Jakarta EE! I'm pleased with the name and I'm also pleased we've got that out of the way so we can move forward as a community and help drive enterprise Java to the next level. I couldn't have said it better than my friend, co-PMC member and CEO of Tomitribe did earlier:
Mike from the Eclipse Foundation wrote a great post on the next thing we're doing around driving Java EE forward: the EE.next Working Group. There isn't really a lot more that I want to say which isn't covered in Mike's article and the point of my post is more to try to encourage everyone to get involved, whether you are representing a corporation, big or small, or just acting as an individual. I've said it before but I'll say it again: the future of Java EE will be determined by the community and you can help in many different ways. Start by joining the working group!
I've written about EE4J a few times before and many others have too, particularly on the name. Back in November, Mike from Eclipse announced that we were going to run a community effort to pick a new name for the Java EE brand once it moves to the Eclipse Foundation. We had a lot of great names submitted from the community by the time the input period ended. The next step was to run through various legal, patent and IP processes to determine whether each name was even open for use. Very similar to the processes we had to go through when we renamed JBoss AS7 to WildFly, in fact. That pruned the list dramatically to the point where we now have only a couple of names left as options. Yes of course we could re-open the suggestion box but that's not going to guarantee a different outcome and in the meantime the Java EE brand doesn't move forward. Therefore, that's why as a member of the EE4J PMC I agree with the original timeline of events and we should simply vote on the two renaming names: Jakarta EE and Enterprise Profile.
Now of course given that I was one of the creators of the MicroProfile effort (now Eclipse MicroProfile) you might be forgiven for thinking I'd prefer Enterprise Profile. It has a certain ring to it and in some ways compliments MicroProfile. However, I actually prefer Jakarta EE and here's why:
So all in all I think Jakarta EE is by far the best choice of the two. And in fact I can't think of a better name now that we've whittled down the list. However, this is a community effort so just remember to cast your vote.
Recently the Java EE Guardians wrote an open letter on Java EE Naming and Packaging. This kicked off a long thread on the EE4J mailing list when Will Lyons, from Oracle, posted a response on behalf of Oracle. I won't go into specific details on the initial letter or Oracle's response as the interested reader can check them out directly. However, I will summarise the key points:
I gave my input on these points in the thread but thought it would be good to pull out the relevant text here. I'll simply include it in quotes and the reader can check out more context by reviewing the archive or joining in on the thread.
First there was this piece ...
"I’m fairly sure I’ve said this before on some lists and also at JavaOne 2017 when we discussed some of this in various meetings but I will repeat here: whilst I would definitely have preferred to keep the javax namespace for new specifications and to perhaps retain the Java EE name for the branding, I understand Oracle’s position. Related to that, I therefore know that no amount of energy expended on trying to change these two things will result in a different outcome. However, I think what Oracle have done to this point in moving Java EE to Eclipse is much more important than a brand name or a Java package name and collectively we should expend that energy in moving the code and community forward collaboratively. EE4J will not fail because it’s not branded Java EE. EE4J will not fail because new specifications cannot be done under the javax package. EE4J will fail if we spend too much time away from driving these specifications forward and adding new specifications to adapt to changes in the developer space.
Therefore, whilst I understand what the Guardians have requested, I feel that we are at a point where we should focus on the positive aspects of what Oracle have done and build on those. Together we move EE4J forward and together we can make it a success!"
Then there was this ...
"When looking at where to move Java EE we (Oracle, IBM and Red Hat) did touch on the standards body option. I’m sure I wasn’t the only one, but I do recall raising the question about OASIS specifically because I know Oracle, IBM, Red Hat and others have worked together in OASIS many times over the years. However, there was universal agreement that whilst OASIS might be the right place for standards efforts such as WS-*, TOSCA and other things which might well be considered “protocol related”, it likely wasn’t the right place for Java and Java EE related activities which are much more developer focussed.
I also recall re-raising this with MikeM from Eclipse and others once we had announced the move to the Eclipse Foundation because clearly what we now have to do within Eclipse is create processes which look very much like those you’d find within an existing standards organisation, such as OASIS or W3C. There are pros and cons with this but ultimately the things which swayed me to say that we shouldn’t standardise within OASIS or elsewhere include the following:
- having the code in Eclipse and standards efforts elsewhere would mean individuals and corporations need to be members of multiple (at least two) bodies. Whilst that might not be too much of a hurdle for corporations, it’s not going to be easy for some individuals and would be a possible impediment to growing the community wide and deep.
- over the last 3 decades (ouch!) I’ve worked in pretty much all of the standards bodies around and whilst they have good processes for what they do, they’re not necessarily the right processes for what the community may need around EE4J. Furthermore, they don’t necessarily move quickly either. I believe we can come up with a bespoke process within Eclipse which feels more a natural part of the development effort than something which is adjunct to it."
I was also asked about the renaming of JBossAS to WildFly, which seems to very long ago now. I won't include the text here because I really want to encourage people who are that interested to read the thread and join in.
I already wrote about the work we, IBM and Oracle have been doing together to move Java EE to a foundation. At the time I couldn't say which foundation but now we know it's Eclipse and that the project will be called Eclipse Enterprise For Java (EE4J). There's a draft charter and it's vitally important that interested people read it and give feedback on the mailing list. There's a lot of pent-up passion and energy around Java EE and it would be so much better if individuals focussed that on the charter at this point than complaining about the name. Yes, I understand that some people feel the name is important to the success of this effort but I can tell you all that there's a lot more to choosing a name for a foundation or massively successful project than just ... choosing the name. Having done this when we renamed JBossAS to WildFly, you've got to do trademark searches, domain checks, legal verifications etc. and of course that the name or acronym doesn't mean something inappropriate in a different language. So getting to a name like EE4J isn't easy and changing it now is simply not going to be possible. Plus you can never please everyone all of the time.
There's a lot to do over the coming weeks and months. Moving the TCKs, specs and sources to the Eclipse Foundation is probably the easiest of the tasks, which isn't to suggest it's going to be easy. We've got to figure out the processes around which EE4J evolves, who leads the specifications, what about compatibility, evangelism, how does the JCP fit in, etc? And it's going to succeed or fail based upon the engagement of the entire Java (EE) communities. If you're invested in Java EE or anything related to it (yes, including Eclipse MicroProfile) then it's a great opportunity to step up and help drive this in an open manner. Gone are the cries of "this is dominated by Sun/Oracle" and "it's not open source". This is now an Eclipse Foundation effort and the best way to ensure this evolves in a direction with which you agree is to join and get involved!
I want to take a moment to thank everyone who has helped so far, obviously including Oracle and IBM. We've just completed the JCP Executive Committee F2F which always precedes JavaOne and the feedback from there when EE4J was presented was positive. Yes there are still a lot of unknowns, many of which I've mentioned above. But generally everyone thought this was a good thing!
JBoss and Fuse has always been about developer focus. Whether you're someone who builds applications with our projects and products, or someone who contributes to the construction of those projects, or a combination of the two, over the years we've been pretty successful at appealing to the Java and JVM communities. With initiatives like JBoss Everywhere, acquisitions such as FuseSource or FeedHenry, we've constantly grown our developer footprint and appeal. How we reach those developers, educate them on what we're doing, how we need their help etc. has always been a multi-faceted effort with JBoss.org playing a central role. If you've been with us long enough then you'll remember that JBoss.org has had a number of personality changes, going from driving interest in JBossAS as a project and other commercial activities, through the introduction of JBoss.com and making JBoss.org a purely project oriented site with focus on our many upstream projects and JBoss Labs, and then back to a more product focus coinciding with our move to give developers free access to our products, and more recently once again adding in more community efforts.
In the past few years we introduced the Red Hat Developer Program which is meant to appeal to a wider community of developers than just JBoss or Fuse. The long term aim has always been to cater to contributor developers (those who help us build our projects) and user/builder developers (those who use our projects and products to build their own applications). Slowly but surely we have moved closer towards that plan and now we are at a point where we have to consider how JBoss.org and developers.redhat.com can work better together. If you hadn't noticed, much of the JBoss developer work had moved to the developer.jboss.org location, leaving the main www.jboss.org page to focus on products (of course there are exceptions, including the various microsites like our research or IoT pages). The eventual plan is to fold the JBoss developer content into appropriate pages within the main Red Hat developer site; that's going to take a while though due to the other services and sites which are hosted from that site. But for now the product-oriented pages need to move over to developers.redhat.com and we are left with a question of where does www.jboss.org point to? There are two obvious options:
Throughout our history JBoss and Red Hat have had an enviable track record of looking for input from our wider communities on a wide range of things we are contemplating. For example, probably one of the biggest I can recall in recent years was the JBossAS rename. It's for that reason I'm writing this blog entry, to inform our communities that we're going to be making a change. I value your input and although I and the team have our own thoughts on the right answer, I don't want to just drop this on everyone without some consultation. After all, www.jboss.org is not a site used only by Red Hat employees! One easy way for us to determine is from tracking your usage and for that reason www.jboss.org will soon show two options and when you land on the homepage you'll be able to either go to developers.redhat.com and find information on product downloads, tutorials etc. or continue to developer.jboss.org and locate your favourite community project and associated information. Let's see how this works and then we'll report back after a meaningful period of time.
By now I'm hoping that most people will have seen the announcement from Oracle around Java EE and possible moves towards open source foundations. Of course there are a few media articles on the topic now because if this does happen it's pretty significant. I haven't got much more I can add at this time from Red Hat that hasn't been said by John Clingan but I did want to echo the sentiments: I think this is a very positive thing to do and likely sits up there alongside Sun's open sourcing of Java as one of the most significant events to happen to the wider Java ecosystem. Of course the devil's in the detail and those details are few and far between at this time, but Red Hat is very happy to support this effort in whatever we we can to help ensure a positive outcome and future for Java EE and its enterprise components. Clearly I also see this as beneficial to our collective MicroProfile efforts and we will have to see how both of these things will evolve over time. Onward!!
Now that the vote has passed and the EC face-to-face meeting in Austin on May 8th and 9th has also concluded, I wanted to write down a little about why we voted NO on JSR 376. Scott has already posted an article on the concerns from Red Hat Middleware teams and other members of the Expert Groups and wider Java community (note that at least 50% of the EG contributed to the document - it is NOT just from Red Hat). This has never been about Java EE versus Jigsaw as some might think; it has always been about the benefits for the wider Java communities and making Java 9 a success: Red Hat, and JBoss before it, has invested a lot in the Java ecosystem over the years and our input on JSR 376 has always been because we want Java and the JVM to continue to thrive; we understand it needs to evolve and sometimes that might mean breaking backwards compatibility. However, there's a huge JVM community out there which has developed over two decades and we have to be cognisant that we need to bring as many of them with us when we do release Java 9 rather than risk driving them to other newer languages. And unfortunately the majority of those community members don't participate in JSR Expert Groups so their feedback, both positive and negative, often comes after the fact. With something as invasive as Jigsaw, where reversing it out of the JVM if it was to break too much is probably impossible to do, it is therefore imperative that the representatives on the EG are confident as much has been done as possible to make moving to Java 9 as easy and natural as possible.
It’s a very complex situation we found ourselves in and I’ve spent months listening to the arguments from all sides, not least of which are our own OpenJDK and middleware teams. I flip-flopped between an abstain vote and a no vote, trying to remain objective on the outcome. On the whole, what swayed me to vote no was not the arguments for why WildFly or any specific module system, such as OSGi, might not work well on Jigsaw: those were important concerns but so were some counter arguments from our OpenJDK team. What did it for me was the belief that Jigsaw as it currently stands still needs modifications: in a world as polyglot as we find ourselves in today, the general lack of consensus in the EG and beyond makes it important we stop and consider the potential impact as I mentioned above; if there are smaller changes which could be made which would mitigate the issues we and others have raised in the wider Java community than just the EG, then I think it’s worth spending a bit more time doing so.
None of us have a time machine to see what will happen or predict the future. I believe I remained objective and I believe I made the right decision. However, I want to make it clear that whilst the Red Hat OpenJDK team, the WildFly team, Hibernate, Drools and many other groups gave input for and against Jigsaw, the buck stops with me: I made the decision and whether anyone believes it is right or wrong, I stand by it. At this stage we all need to come together and work together to make Java 9 a success.
I want to finish by returning to the idea of who was concerned about Jigsaw. Whilst the focus seems to only fall upon Red Hat and IBM having concerns, the document Scott posted has wider representation that that. Other discussions around Jigsaw, such as on InfoQ and social media, are full of similar concerns from individuals and other companies than just ourselves. I can't speak for IBM but I can say that this is not a vote we wanted to take in the way we did and it's certainly not a vote we entered into lightly. Whatever the outcome of the vote I hope that the Jigsaw EG, the OpenJDK teams and Red Hat can move forward positively to continue to ensure Java and the JVM are relevant to a wide range of enterprises. That's certainly our intent and we won't be putting roadblocks in the way of collaboration; if everyone can take what has been said and done on all sides to date from the perspective of assuming positive intent then I'm sure we can make this work!
Back at Red Hat Summit and DevNation we announced that we were working with IBM, TomiTribe, Payara and LJC (and now SouJava!) in an upstream community effort to gain experience on best practices for developing microservices using Java EE, which we called the MicroProfile. Obviously our own efforts around WildFly Swarm fed into these discussions and we've been actively participating in the forum discussions ever since. Now at DevNation we committed to agreeing on a 1.0 version of our project, i.e., what those baseline (minimum) EE components would be for developing meaningful microservices, before JavaOne. At the time we thought it would be JAX-RS, JSON-P and CDI but we really wanted wider input from users and developers. We got a lot of input and I encourage anyone who hasn't joined the group yet to do so if you want to help influence the collaborative efforts.
Well the good news is that we finished 1.0 a few weeks ahead of schedule with 6 different implementations! You can read more about the announcement but the obvious question is what next? Technically Java EE still has a lot more to offer microservices and we've been discussing these on the mailing list, including JPA, JTA (yes, I think transactions have a role to play!), Bean Validation and Concurrency Utilities, to name but four. We need to look at extensions to these efforts, or things which go beyond where they currently sit. For example CQRS is important for more advanced microservices developers. Monitoring, logging and tracing in a distributed system is critical on a number of fronts, not least of which is debugging performance problems and errors, so we need to do more here. One of my pet favourites around microservices is the move towards reactive and asynchronous, as epitomised by projects like Vert.x. It's much more than just making JAX-RS a bit more asynchronous so we have a bit of a slog here to make improvements in Java EE components/standards; maybe we'll decide it just isn't worth it and we need to look at defining new things from scratch.
I could go on and on with some of the technical things I believe we need to look into next, including service discovery, components from Netflix OSS, CDI annotations for things like circuit breakers and of course language level features such as JDK 8 Lambdas and Streams, or Java 9 modularity, but you can find more details at the official announcement blog. I will point out one other thing though: we've got to move away from just assuming HTTP is the only way microservices communicate. Yes, HTTP is convenient, but a text-based protocol is not the way to go if you want high performance. HTTP/2 helps, as will WebSockets (yes, more benefit from Java EE) but we need to look at messaging solutions (not just JMS). Oh and fault tolerance, reliability and security are other areas we need to focus on - it's going to be busy so get involved and help us break this down into smaller challenges!
Of course there's more than the technical aspects to consider. We now believe we have something worthy and useful in MicroProfile 1.0. We've always talked about standardisation once we have gained enough experience - that's where standards bodies work really well. This is something we need to discuss in the community, as with everything else we've done so far, but my personal opinion is that we are ready to move MicroProfile 1.0 to a standards body. Which standards body is again open to discussion, but it would seem logical for the JCP to play a role here since at the moment we're based entirely on Java EE. Get involved! Give your own opinion. Finally, we're going to move the existing MicroProfile effort to a Foundation. Discussions are on going (yes, again in the upstream forum) but I think we're close to a decision and should be able to announce something real soon now! Stay tuned!
OK that's it for now. It has been a great community effort around MicroProfile since we announced it only a few small months ago. My thanks go out to everyone who has contributed in a small or large way, no matter which company you work for or if you're an individual contributor. It all helps us to understand where enterprise Java microservices need to head. Please keep involved and help us shape the future of the industry! And if you're around at JavaOne ...
Last week at DevNation we announced the MicroProfile, which is work we're doing with IBM, TomiTribe, Payara and the London Java Community, amongst others. Since then I've seen a few people write articles or talk about it on social media and there appear to be a few things we definitely need to clarify.
For a start, the work we're doing is not a standard. As I mentioned during the keynote, we may eventually take it to a standards body (more on that later), but at this stage the world of microservices is relatively new and evolving, let alone the world of enterprise Java-based microservices. In general, standardising too early results in ineffective or otherwise irrelevant standards so we don't want to consider that until we're further down the line. Now that doesn't mean we won't be using standards to develop. Far from it, as I mentioned we're thinking about a minimum profile based on Java EE (probably 7 since 8 isn't yet finalised) initially. Portability and interoperability are key things we want to achieve with this work. We may never be able to get everyone to agree on a single implementation, but at least if they can port their applications or communicate within heterogeneous deployments, then that's a much more realistic goal. After all microservices, and SOA before it, isn't prescriptive about an implementation, and probably never should be.
Although we're starting with Java EE as a basis, we're not going to tie ourselves to that. If you look at some of the other approaches to microservices, such as Netflix OSS, or OpenShift, there are features such as logging, or events or even asynchrony, which aren't currently available as part of EE. Again, I mentioned this during the announcement, but we all expect this work to evolve enterprise Java in these and other areas as we progress. Java EE represents an evolution of enterprise middleware and we all believe that enterprise Java has to evolve beyond where it is today. Maybe we'll take these evolutions to a standards body too, but once again it's way too early to commit to any of that.
Another thing which we brought out during the announcement was that we want this work to be driven through good open source principles. We're working in the open, with a public repository and mailing list for collaboration. We're also not restricting the people or companies that can be involved. In fact we want as wide participation as possible, something which we have seen grow since the original announcement, which is good! This means that our initial thoughts on what constitutes the minimum profile are also open for discussion: we had to put a stick in the ground for the announcement, but we're willing to change our position based on the community collaboration. We've placed few limitations on ourselves other than the fact we feel it important to get an agreed initial (final) profile out by around September 2016.
I think this leaves me with just one other thing to address: which standards body? The obvious candidate would be the JCP given that we're starting with Java EE. However, as I mentioned earlier we may find that we need to evolve the approach to incorporate things which go way beyond the existing standard, which may make a different standards body more appropriate. We simply don't know at this stage and certainly don't want to rule anything in or out. There's enough time for us think on that without rushing to a decision.
Last week at Red Hat Summit several of us, myself included, paid tribute to the fact that June 2016 was the 10 year anniversary of closing of the deal which brought Red Hat in to JBoss. I had a few things to say about this during my portion of the DevNation keynote, highlighting the CDI work we've done, the various acquisitions such as FuseSource and FeedHenry, or the innovation around projects such as Vert.x and WildFly Swarm. As I mentioned at the time, we've accomplished so many things over the last decade that I really couldn't hope to do them justice in a single keynote. It truly has been a defining decade for enterprise Java within Red Hat.
It was also an emotional anniversary for me which didn't really hit until Summit, or maybe it was because of Summit. While there I met and interacted with people I've known for many of those 10 years in Red Hat and who have worked as part of the middleware efforts, but some of whom have now moved on to other areas of Red Hat. It was great to see them doing so well but slightly sad that we're not working as closely these days. Another change was that the JBoss/JUDCon keynote and associated demo, which started out years ago playing to a packed room of a hundred or so has now become part of the main keynote stage in front of thousands: wonderful to see!
10 years of JBoss in Red Hat has been a great ride. We've been able to act as a catalyst for innovation both inside and outside of Red Hat. The business has grown from only a couple of products to a dozen or so. Revenues are also up significantly. And the teams, including engineering, QE, docs, product management etc. have also exploded in size. I look forward to what the next 10 years will bring! Onward! And We Love You !
I was at DevoxxUK last week on a panel session about the future of Java EE (my thanks to Antonio for inviting me). I suppose it wasn't surprised that you had all of the panel members united in their view that not only has Java EE been good for the enterprise middleware space, and of course it has a future role to play in areas such as cloud and IoT. It wouldn't be too hard to suggest that the panelists weren't objective in their assessment but that would be too easy and overlook the reality: Java EE has been the most successful cross-vendor enterprise middleware standard we've ever known; of course it's not perfect; of course there have been a number of iterations required to improve its applicability to an ever evolving set of use cases. But warts and all, Java EE implementations such as EAP have been deployed widely across the globe and sit at the heart of many of the mission critical environments we take for granted, such as banks, hospitals, air traffic control systems.
I've been around the proverbial block long enough to appreciate the incredible amount of technical work that has gone into Java EE and J2EE before it. But what I appreciate more, and what some people are too quick to ignore, is the incredible amount of cross-vendor/cross-community agreement that has gone into these standards. We often take for granted how well, on the whole, open source developers can collaborate under the banner of a single open source project. However, until relatively recently open source was not a main source of collaboration for Java EE. Even then, working within standards bodies can be a long, slow process, fraught with the usual tensions of getting agreement on interfaces, behaviours etc. when there are already multiple competing implementations for this or that feature. And the amount of time and effort this takes is often proportional to the number of participants. Take a look at how many people have worked on Java EE over the years and marvel at what they managed to achieve, whether or not you agree with it all.
As I've said many times in the past, the principles on which Java EE are based are pretty common to distributed systems in general. CORBA has them. DCE before it. Countless bespoke implementations both before and after, as well as currently, need some or all of the same capabilities you find within Java EE. With the new generation of EE implementations, such as EAP, which are agile, small and extremely fast, getting access to high performance messaging, bullet proof transactions, or something else by using EE is easier than many people believe and often easier than some of the new generation of frameworks in Java or other languages.
Back to the DevoxxUK panel: during the event several people in the audience expressed their agreement with the assessment that Java EE has a future, or at least should be allowed to aim for one, but that they were surprised this was the first time they were hearing from the vendors and communities represented by the panel that they were willing to work together to try to assure that future. I suppose on the one hand we've all felt that actions speak louder than works, and the fact that we've all been working together for years on the betterment of Java EE was assumed to be sufficient evidence that we'd continue to do so - are continuing to do so. However, given rumours and other concerns about the future of Java EE, I can certainly empathise with developers who want to hear that the major vendors are standing behind it. Well Red Hat and those on the panel at DevoxxUK hopefully made it clear: we are prepared to continue innovating with and on Java EE, and it's a key part of our strategy.
No one starts out wanting to build a monolith. There are no design meetings where the architect or developers say "you know what? I think it'd be a great thing if we built something that will be hard to evolve and maintain." I think it's also fair to say that conversations like "we've got a great architecture for our system that has helped us be successful, so we need to be sure that it evolves towards a big ball of mud" rarely happen!
And yet monolithic applications do exist. Probably less than many people might want to admit, but they are there nonetheless. So the question has to arise: why? I suppose there's another related question: how? As with so many things in this life, there's no one straight answer; it's a combination of things including:
- Expediency; far too often it's just too easy for developers to hack solutions into an otherwise good architecture without spending time to understand whether that breaks the architecture. What starts as a simple, small hack can also then grow, acting as a catalyst, and a small break in the architecture then turns into a fracture.
- Lack of architect (leadership); the original architect(s) leave the project and those who come in to replace them (if they are replaced) can't control the developers or perhaps don't understand the architecture enough to ensure it remains "pure". Likewise, different developers coming into the project to either add to or replace those there already, can dilute the group knowledge and understanding of the architecture, leading to unforeseen and accidental divergence from the original plan.
- Natural evolution; any system than can be said to be architected has a point at which it's simply impossible to evolve and retain the original architecture. Take a look at any (historic) building which may have once been considered an architectural marvel and if it was left mainly alone (not extended) once complete then it's likely still something to behold and admire. But if it had extensions, new wings etc. then it's likely to be a monstrous carubuncle, unless the original architect was involved, or someone who appreciated/understood the original. Sometimes it's just easier to start from scratch and approach the problem afresh, than try to tack on new features.
- Related to the above, sometimes people try to extend software systems (services) to do more than they really should and in doing so break the architecture or create monoliths.
- Poor tools with which to visualise the software system/architecture, leading to making it harder to track changes and ensure they don't move the system towards an unmanageable monolith.
Now nothing I've mentioned so far has been specific to localised applications. It's just as applicable to distributed systems and in fact in a distributed environment the architectural issues can become even more important to understand and track. If you've arrived at a monolith then trying to fix that may involve breaking it into components/services/microservices which reside in a distributed environment, but that's not necessarily the only way, or the best way, in which to resolve the monolith problem. In fact if you don't understand the architectural issues which have resulted in the monolith then breaking it into components is more likely to result in a distributed monolith (or micromonoliths) than to fix the problem!
Yes, I mentioned the microservices word above for the first time and this is really an article about them again. As I've mentioned elsewhere, I believe in and understand the need for distributed systems composed of (micro) services. However, what worries me about some of the current emphasis around microservices is that somehow they will naturally result in a better architecture. That's simply not the case. If you don't put in to place the right processes, design reviews, architecture reviews, architects etc. to prevent or forestall a local monolith then you've no hope of achieving a good microservices architecture. And if you don't keep them in place then there's a good chance you'll evolve towards a distributed monolith.
You've developed a microservice. You know it is because it does one thing well, can be independently versioned as well as deployed, and best of all the consultants you employed to help say it is too! Maybe you've even had it in production use for a while, receiving positive feedback on the benefits a service oriented approach brings. Let's assume you developed the service so it can run within a Linux container (some other container technology, including one based on the JVM, would be just as suitable for this example.) Hopefully you've embraced immutability and therefore take the approach of producing a new instance each time you need to make a modification. So far, so good.
As I've mentioned before, once you start down the microservices road, as with other services approaches dating back beyond even CORBA, you immediately enter the world of distributed computing, with all that entails. Therefore, it is inevitable that at some point either you, your team, or some group of developers at some point in the future, will wonder what they can do to improve performance or reliability in the face of distributed invocations and partial, independent failures. Co-location of services will likely be close to, if not top of, the list of things to try. Let's face it, the ability to improve the networking interconnect is limited in any meaningful timeframe, as is finding money to purchase machines with higher MTTF and lower MTTR (plus entropy increases, so you're going to have failures eventually). That leaves moving services (physically) closer together to reduce the network latency and increase the probability that they fail as a logical unit. Ok let's stop there for a second and back up a bit: just to be clear, I'm talking about services which are related closely such that they rely upon each other to work though can be invoked independently as well.
At some point some group or groups of developers will come (back around) to making microservices infrastructures dynamic in so much that individual placements of services are (initially) made based on heuristics from inter-service communications (interactions) to reduce network overhead. And these placements will (eventually) be computed frequently to enable services to be redeployed if those usage patterns change and new clients come in to play which need the services (or copies) placed closer to them. So it goes that eventually microservices will want to be placed within the same container. As I mentioned before, this could be the same Linux container, especially if each service is a separate process, or could be in the same language container, such as an OSGi container if each service is an OSGi bundle. And whilst these co-location deployments could be done in a volatile manner initially, such that the reboot of the container causes the services to no longer be co-located, it makes sense that a new durable instance of the container be created if the updated configuration proves valuable.
However, that then leads me finally to the question in the title: you had multiple microservices before they were co-located in the same container but does that change now? Are they still microservices? Maybe not if they can't be redeployed independently, but as I mentioned earlier, maybe they aren't that independent anyway. But in which case maybe they should have been collapsed into a single microservices in the first place? Lots of questions!
To be perfectly honest I'm not hung up on the "independently deployable" aspect of microservices in general. I think dependencies between components, objects, services etc. in distributed systems are things which may ebb and flow over time and usage patterns. I think the more important aspects are the service oriented nature, with a well defined contract between user(s) and service, quick deployment ('quick' being a relative term), and well defined APIs. Therefore, in my book these co-located microservices may still be microservices, or maybe composite microservices (what about a milliservice?) But one thing I'm sure of is that some people will disagree and the "goodness" which is the lack of standards in this area, will encourage these kinds of discussions for a while to come.